Hello, so I got ENOSPC during a routine software update and doing a df -h shows my / partition as:
/dev/mapper/system-root 40G 40G 457M 99% /
Problem is that considering what is installed on this machine, the 40G figure is super unrealistic, so I fire up filelight (essentially a GUI version of du) and it reports 12.1 GiB, which is entirely believable.
I have already deleted a number of snapshots (that zypper makes automatically) and it hasn’t made the blindest bit of difference to the space usage reported by df. Trying a btrfs balance start / errors out with ENOSPC after a few seconds.
Needless to say, this is the first and the last time that I make the mistake of using btrfs on a production machine, but since I’m stuck with it I’d be grateful for any ideas.
Hi
Have you run snapper list to check all are deleted? Have you seen the btrfs maintenance routines run (journalctl) or you might need to run manually. Sure there is not some big file lurking somewhere in the likes of tmp, or lots of logs (something hammering away at them)? Have you configured snapper at all?
Check the hidden trash files in /var/.Trash-0 and /opt/.Trash-0 and also /home/.Trash-0. As root, delete the files in /file subdirectories in those trash directories. There may be more hidden trash cans on your disk that you should look for. I found 70 gig of deleted files in those trashcans that were really supposed to have been deleted., were named as deleted but were still taking up disk space. I too had df showing 97 gig of / used and du only 20 gig of /used. I started a thread about this a month or so ago. Look back at that. I also have btrfs root partition.
I don’t know why this can’t be fixed so people don’t go through unnecessary repartitioning to increase root partition size or even buying another harddrive. This is a flaw in the system.
I now check these regularly and manually delte the files as needed.