Hello, everyone. Recently I finally decided to update my system, and right after the update ran into a problem: before update baobab showed ~22 GB avaliable space, and after the update it went down to around 8.
Here’s some info, that might be relevant:
df output:
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 788700 1976 786724 1% /run
/dev/nvme0n1p8 53050368 48246568 4054792 93% /
tmpfs 3943496 0 3943496 0% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
/dev/nvme0n1p8 53050368 48246568 4054792 93% /home
/dev/nvme0n1p7 998060 133944 795304 15% /boot
/dev/nvme0n1p1 364544 89768 274776 25% /boot/efi
tmpfs 788696 104 788592 1% /run/user/1000
du -h /
shows 23G, du -h /home
— 13G. Overall I have 54.3G disk space, so (23+13)/54 doesn’t add up to 93%
sudo lsof | grep deleted | wc -l
shows 8433 deleted files that are still in use.
I also tried booting with liveUSB and running ‘check’ on partition via GParted.
I did some research online:
- https://forum.manjaro.org/t/baobab-shows-14gb-less-usage-where-is-the-rest/109527 - seems like a similar problem, but does not address huge du/df difference, also doesn’t provide solution for me
- https://unix.stackexchange.com/questions/414417/du-not-accounting-for-space-shown-by-df helped me understend difference between du/dh, so I provided output of lsof as suggested.
- a lot of other stackoverflow posts, all having similar answers, that didn’t help me
I tried some methods to locate what consumes all the space, but couldn’t figure it out. Also, the problem seems to be getting worse (right now baobab shows only ~5GB avaliable space). Can you help me find the source of the problem (and ideally also help me solve it :) )?
because you’ve updated be tween releases you may have a large cache of file for apt
you may want to run
sudo apt-get autoclean
to remove old files that aren’t in the repo (replaced with new versions)apt-cache stats
will tell you info about the cacheRunning
sudo apt-get autoclean && sudo apt-get autoremove
was the first thing I tried.I am not sure, how do I interpret output of apt-cache stats?
spoiler
Total package names: 126893 (3,553 k) Total package structures: 122145 (5,374 k) Normal packages: 81989 Pure virtual packages: 2797 Single virtual packages: 22954 Mixed virtual packages: 2708 Missing: 11697 Total distinct versions: 101553 (8,937 k) Total distinct descriptions: 180829 (4,340 k) Total dependencies: 609988/159599 (14.8 M) Total ver/file relations: 32564 (782 k) Total Desc/File relations: 49757 (1,194 k) Total Provides mappings: 50727 (1,217 k) Total globbed strings: 239740 (5,895 k) Total slack space: 65.4 k Total space accounted for: 47.7 M Total buckets in PkgHashTable: 196613 Unused: 109956 Used: 86657 Utilization: 44.0749% Average entries: 1.40952 Longest: 17 Shortest: 1 Total buckets in GrpHashTable: 196613 Unused: 103120 Used: 93493 Utilization: 47.5518% Average entries: 1.35725 Longest: 8 Shortest: 1
A reboot will make whatever processes that are still using those deleted files let go of them. Maybe that solves your problem. If not, ncdu will help you find large files and directories.
I’ve already tried rebooting (as mentioned in the post, I’ve run GParted ‘check’ from liveUSB, reboot after. Also, I’ve done it seperately). And ncdu shows basically the same result as baobab — it doesn’t add up to 93% disk usage from df
I want to thank everyone for the help!
I was finally able to find the issue. Thanks to @slappy@lemmy.blahaj.zone 's question regarding my filesystem type, I decided to look into it.
I use btrfs, and this command showed me, that I have a lot of snapshots made by apt.
$ sudo btrfs subvolume list -s / ... ID 318 gen 2617038 cgen 2566262 top level 5 otime 2024-02-13 06:59:10 path @apt-snapshot-release-upgrade-jammy-2024-02-13_06:59:10
It was probably possible to determine how much space each of them was occupying, but I decided to simply delete them all and be done with the issue. So I installed
apt-btrfs-snapshot
and rundelete-older-than 0d
.As a result, I now have 29 Gb and no backups, which is fine with me.