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 :) )?
I zeroed all the files in /var/log, but it had practically no effect on the disk usage
deleted by creator
I’m using btrfs When I grew the partition, I only used GParted