i3status gives different free space than df

[Mikaela]

• i3status 2.12 (2018-05-11) © 2008 Michael Stapelberg and contributors
• Debian GNU/Linux 10 (buster)
• full config file

I am using:

order += "disk /"
order += "disk /home"
...
disk / {
        format = "/: %free"
}

disk /home {
        format = "/home: %free"
}

and i3status shows this:

However in df -h I see:

Filesystem      Size  Used Avail Use% Mounted on
...
/dev/sda7        49G   34G   13G  74% /
...
/dev/sda9       618G  533G   54G  91% /home
...

Am I using incorrect syntax or why is there so great difference? 13G vs 15 GiB and 85,4 GiB vs 54 G? I noticed this some days ago when I had gotten my disk full and rsync was errorring me while i3status said I had space left still.

Here is full df -h in case it helps, I have snapd installed, so it's messy:

Filesystem      Size  Used Avail Use% Mounted on
udev            3,7G     0  3,7G   0% /dev
tmpfs           743M  9,6M  734M   2% /run
/dev/sda7        49G   34G   13G  74% /
tmpfs           3,7G  273M  3,4G   8% /dev/shm
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs           3,7G     0  3,7G   0% /sys/fs/cgroup
/dev/loop6       54M   54M     0 100% /snap/core18/970
/dev/loop0       36M   36M     0 100% /snap/gtk-common-themes/1198
/dev/loop2      141M  141M     0 100% /snap/gnome-3-26-1604/88
/dev/loop4      374M  374M     0 100% /snap/anbox/158
/dev/loop1      109M  109M     0 100% /snap/bitwarden/17
/dev/loop5      132M  132M     0 100% /snap/rambox/4
/dev/loop7       18M   18M     0 100% /snap/bw/11
/dev/loop3      112M  112M     0 100% /snap/rambox/2
/dev/loop9       88M   88M     0 100% /snap/go/3739
/dev/loop8       89M   89M     0 100% /snap/core/7169
/dev/loop11      74M   74M     0 100% /snap/desktop-habitica/1
/dev/loop12     132M  132M     0 100% /snap/rambox/5
/dev/loop10      18M   18M     0 100% /snap/bw/12
/dev/loop14      17M   17M     0 100% /snap/bw/10
/dev/loop13     149M  149M     0 100% /snap/fluffychat/12
/dev/loop15     128M  128M     0 100% /snap/syncplay/3
/dev/loop16      54M   54M     0 100% /snap/core18/1013
/dev/loop17      89M   89M     0 100% /snap/core/6964
/dev/loop19     141M  141M     0 100% /snap/gnome-3-26-1604/86
/dev/loop20     121M  121M     0 100% /snap/om26er-gradle/5
/dev/loop18      88M   88M     0 100% /snap/go/3947
/dev/loop21      35M   35M     0 100% /snap/gtk-common-themes/1122
/dev/loop22     158M  158M     0 100% /snap/signal-desktop/111
/dev/loop23      36M   36M     0 100% /snap/gtk-common-themes/1269
/dev/loop26     109M  109M     0 100% /snap/signal-desktop/114
/dev/loop25     150M  150M     0 100% /snap/fluffychat/13
/dev/loop24     152M  152M     0 100% /snap/gnome-3-28-1804/59
/dev/sda2        96M   69M   28M  72% /boot/efi
/dev/sda9       618G  533G   54G  91% /home
tmpfs           743M  168K  743M   1% /run/user/1000
/dev/fuse       250G   50M  250G   1% /run/user/1000/keybase/kbfs

[thrasymache]

Short answer - you should be using %avail rather than %free, which is what df is actually reporting.

Long answer - If you take the difference between the used space and the total space, you will get the free space that i3status is reporting. 49GB - 34GB = 15GB and 618GB - 533GB = 85GB. I recently came across this and got similarly bothered, and found in the coreutils FAQ or somewhere like that, that many file systems reserve a few percent of space that is free, but not available to normal users. Only root is permitted to use that space (presumably to recover a system in an emergency), and that the file systems will work sub-optimally long before you get to that limit.

[Mikaela]

Thank you :)

I talked about this with some people before I finally opened this issue and they found this weird when I said I was using ext4. I didn't know of ext4 having emergency space, but I would have expected this to be it with btrfs.

[thrasymache]

You're very welcome. :-)

I'm also using ext4 and thought I'd found a bug in df (and since it was in the FAQ I'm guessing that several people before me had come to the same conclusion).