I noticed that I only had 5 GiB of free space left today. After quickly deleting some cached files, I tried to figure out what was causing this, but a lot was missing. Every tool gives a different amount of remaining storage space. System Monitor says I’m using 892.2 GiB/2.8 TiB (I don’t even have 2.8 TiB of storage though???). Filelight shows 32.4 GiB in total when scanning root, but 594.9 GiB when scanning my home folder.
Meanwhile, ncdu
(another tool to view disk usage) shows 2.1 TiB with an apparent size of 130 TiB of disk space!
1.3 TiB [#############################################] /.snapshots
578.8 GiB [#################### ] /home
204.0 GiB [####### ] /var
42.5 GiB [# ] /usr
14.1 GiB [ ] /nix
1.3 GiB [ ] /opt
. 434.6 MiB [ ] /tmp
350.4 MiB [ ] /boot
80.8 MiB [ ] /root
23.3 MiB [ ] /etc
. 5.5 MiB [ ] /run
88.0 KiB [ ] /dev
@ 4.0 KiB [ ] lib64
@ 4.0 KiB [ ] sbin
@ 4.0 KiB [ ] lib
@ 4.0 KiB [ ] bin
. 0.0 B [ ] /proc
0.0 B [ ] /sys
0.0 B [ ] /srv
0.0 B [ ] /mnt
I assume the /.snapshots
folder isn’t really that big, and it’s just counting it wrong. However, I’m wondering whether this could cause issues with other programs thinking they don’t have enough storage space. Steam also seems to follow the inflated amount and refuses to install any games.
I haven’t encountered this issue before, I still had about 100 GiB of free space last time I booted my system. Does anyone know what could cause this issue and how to resolve it?
Your btrfs snapshots are possibly counted separately by all the regular tools. They simply go into every directory they can find and add up the size of the files they see. They do not care if they are looking at an identical snapshot of the folder next to them, they simply add it all up.
Use
sudo btrfs filesystem show
(and maybe add a path behind it, I am not sure). That will give you the true usage.sudo btrfs filesystem show
seems to display a reasonable amount.Label: none uuid: af5f864d-2de9-48a9-b521-5923dc08c9e3 Total devices 1 FS bytes used 867.13GiB devid 1 size 922.12GiB used 921.12GiB path /dev/mapper/system-root
This makes sense. When you use a copy-on-write block device, it is doing things below the level of the filesystem, so you have to use cow-aware tools to get an accurate view of your used disk space. For example, if you have two files that are 100% deduplicates at the cow-block level, they could show up as different nodes on the filesystem and would appear as using twice the space in the filesystem as they do on the block device. Same would go for snapshots and compressed blocks.