[SOLVED] df shows 53G disk usage, but du only 14G

[wuschl]

Hi there!

Title says it all. Here ist the outpout from df -h:

Terminal

Filesystem Size Used Avail Use% Mounted on
rootfs 60G 53G 6.2G 90% /
/dev/mmcblk0p2 60G 53G 6.2G 90% /
devtmpfs 125M 4.0K 125M 1% /dev
none 25M 396K 25M 2% /run
/dev/mmcblk0p1 34M 20M 15M 58% /boot
/dev/mmcblk0p2 60G 53G 6.2G 90% /home
/dev/mmcblk0p2 60G 53G 6.2G 90% /lib/modules
/dev/sda1 2.8T 1.3T 1.5T 45% /home/xbian/media
/dev/mmcblk0p2 60G 53G 6.2G 90% /xbmc-backup

Here from sudo du -sh --exclude='*/home/xbian/media*':

Terminal

14G .

What's wrong and eating up all my disk space? I googled and therefore tried "lsof | grep deleted" to be sure that no process is locking big files. But the output does not seem so:

Terminal

init 1 root 9w REG 0,16 83 193186 /var/log/upstart/restore-home.log.1 (deleted)
init 1 root 17w REG 0,16 221 193181 /var/log/upstart/xbmc.log.1 (deleted)
splash 110 root 1u CHR 136,3 0t0 6 /dev/pts/3 (deleted)
splash 110 root 2u CHR 136,3 0t0 6 /dev/pts/3 (deleted)
xbmc.bin 465 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
VCHIQ 465 742 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
xbmc.bin 465 743 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
xbmc.bin 465 744 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
HDispmanx 465 752 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
HTV 465 753 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
HCEC 465 754 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
xbmc.bin 465 755 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
ILCS_HOST 465 756 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
XBPyThrea 465 760 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
XBPyThrea 465 761 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
XBPyThrea 465 762 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
xbmc.bin 465 767 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
xbmc.bin 465 768 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
xbmc.bin 465 769 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
xbmc.bin 465 770 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
xbmc.bin 465 771 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
CEventSer 465 772 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
CTCPServe 465 773 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
AirPlaySe 465 775 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
AirTunesS 465 778 xbian 3r CHR 1,9 0t0 23 /dev/urandom.orig (deleted)
python 812 root 3w REG 0,16 1240 193183 /var/log/upstart-xbmc-bridge.log.1 (deleted)

Has anyone help here?

[wuschl]

Nevermind... The problem just want away overnight as my automated download system overreached the disk limit. Now df shows the right disk usage...

[mk01]

@wuschl,

just to make this clear.

although there is /, /home and /lib/modules as separate mounts, all three are just sub-volumes of one btrfs filesystem - all three share one common space - size of partition.

that means if you rootfs (system) eat up 500MB and you home 50GB, they will all show 50,5 GB used.

btw: if you want to prevent mounts from being calculated in total, just add "-x" switch to "du". it means don't traverse outside filesystem.

Code:

du -shx /

will sum / without /home and without /lib/modules (and possibly other mounts in /media, /mnt …)

[wuschl]

Thanks for your reply! I am aware of the difference between my mount points and partitions. Therefore I excluded /home/xbian/media as it is my external hd. Option -x would have been more accurate, but since my other partitions are not that big I excepted that error in measurement.

But this is no explanation for the difference between df and du, in special because now the calculation seems right...

[mk01]

snapshots.

Code:

btrfs-auto-snapshot list //

another possibility (although this can not make THAT big diff) is metadata. since btrfs introduction, df wasn't considering metadata size. now it is. but du doesn't.

so if you check

Code:

btrfs fi df /

data + metadata should be ~ aligned with df usage. du will never come to this number. but again this is just to explain all possibilities. metadata could be 15, maybe 20%, not actually 300%.