3

I appear to have lost a couple of GB in an ext4 root filesystem (under llvm on centos 7.1 in a VMWare ESX VM if that matters).

[someone@somewhere ~]$ sudo du -xsm /
4561    /

yet:

[someone@somewhere ~]$ sudo df -m /
Filesystem                 1M-blocks  Used Available Use% Mounted on
/dev/mapper/vg_sys-lv_root      8944  7562       956  89% /

I thought maybe something was under a mount point, so I tried this:

[someone@somewhere ~]$ sudo mount --bind / /vp
[someone@somewhere ~]$ sudo du -xsm /vp
4561    /vp

Maybe a deleted file still in use by a process:

sudo lsof | grep deleted

Doesn't show anything significant.

Nor does looking for sparse files using the following command as root (command found here):

find / -type f ! -size 0 -exec perl -le 'for(@ARGV){open(A,"<",$_)or next;seek A,0,4;$p=tell A;seek A,0,2;print if$p!=tell A;close A}' {} +

So, where else could my data be, what does df know that du doesn't in this case? I also checked df -i and less than half the inodes are in use.

1

2 Answers 2

3

Other possible explanations:

  • you're in a chroot or mount namespace and don't have access to the whole filesystem. You could tell by running ls -id / which gives 2 if you're not in a chroot/mount namespace.
  • The file system is corrupted.
  • The space is in use by one of the special inodes. You can use debugfs and issue some stat <3>, stat <4>... to verify.
  • The space is in use by a deleted file, that deleted file is open by a process in another pid namespace (and you're not in the root pid namespace).
  • The space is in use by a deleted file, that deleted file is not open by any file, but is for instance connected to a loop device (losetup -a to check).

Note that there's no reason sparse files would contribute to the discrepancy between du and df.

3
  • Thanks for the suggestions, sadly, the only one I can't rule out is 'The file system is corrupted.' Time to restore a backup and hope this doesn't happen again I guess.
    – jankeir
    Commented Mar 10, 2016 at 10:55
  • @jankeir, does it do it as well after a reboot? Have you tried a fsck to check whether it's actually corrupted? You can do a fsck on a lvm snapshot if you don't want to reboot. Commented Mar 10, 2016 at 11:47
  • We booted a vmware snapshot with a rescue disk iso and there the filesystem usage was normal and a fsck didn't show any issues, so we rebooted the machine and it's fine now. Not sure what caused our problem but I'll accept your answer as it does answer the question about where disk space could be.
    – jankeir
    Commented Mar 15, 2016 at 8:17
1

There are multiple things the file system could spend disk space for, which are not related to file contents.

df takes the number of used and available blocks directly from the file system, while du just sums the size of blocks allocated to each file, so any unrelated FS data structures are not accounted.

It's totally ok that du shows less used space than df does. The strange thing is that the difference is so huge, especially for a rarely modified root partition. Have you tuned your FS somehow? Have you also tried du --inodes to compare with df -i?

2
  • Hmm, there's a small difference between df -i and du --inodes: du --inodes -sx / gives 30800, df -i / gives 31642.
    – jankeir
    Commented Mar 10, 2016 at 10:44
  • @jankeir small difference here is fine
    – sshilovsky
    Commented Mar 11, 2016 at 12:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .