4

I used du to list all folders and sort by size, the results simply doesn't add up to how much disk space is used(using df). There's about 20G in discrepency, why?

[root@xxx lib]# du --max-depth=1 -h /| sort -n -r
310M    /lib
123M    /root
96K /dev
88M /etc
75G /
73G /var
30M /sbin
20M /boot
20K /tmp
18M /lib64
16K /mnt
16K /lost+found
12K /home
8.0K    /srv
8.0K    /selinux
8.0K    /opt
8.0K    /misc
8.0K    /media
7.0M    /bin
1.2G    /usr
0   /sys
0   /proc
[root@xxx lib]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      298G   94G  189G  34% /
/dev/sda1              99M   26M   69M  28% /boot
tmpfs                 2.0G     0  2.0G   0% /dev/shm
strugee
  • 14,951

2 Answers2

11

That's because du and df measure different things.

man du says:

du - estimate file space usage (...) Summarize disk usage of each FILE, recursively for directories.

and man df:

df - report file system disk space usage

File systems have inode tables, journals etc. which are not summarized by du. It isn't only Linux-specific, but rather UNIX-specific (or even UNIX-filesystem-specific). Because UNIX processes use files for everything (I'm simplifying) i.e. writing to log files, there could be also an open file descriptor problem in this case causing different du and df outputs.

Jens
  • 1,752
  • 4
  • 18
  • 36
Grzegorz Rożniecki
  • 211
  • 1
    Correct. Also of interest, many filesystems including ext3 are structured such that directory metadata can grow, but not shrink. So, if you have a high-churn folder (such as a mail spool), the space used by the metadata can grow and grow and grow. Replacing it with a new directory periodically can dramatically drop disk usage. – jmtd May 26 '11 at 13:18
  • Given 0 /sys it looks like du also doesn't include directory tables - which is odd, because they do have a user-visible size - ls -ld [some dir] will show it (often 4096, one filesystem block, for small directories on ext2) – Random832 May 26 '11 at 15:42
  • @Xaerxess: While this is technically possible, it's unlikely that deleted files or race conditions (another possibility for du to miss things) would account for 20GB. – Gilles 'SO- stop being evil' May 26 '11 at 21:56
  • 1
    @jmtd: A high-churn folder would grow to the maximum-ever size and then stop. – Gilles 'SO- stop being evil' May 26 '11 at 21:56
  • @Random832: No, du includes directory tables. The size is 0 for /proc and /sys simply because these filesystems report a size of 0 for everything. – Gilles 'SO- stop being evil' May 26 '11 at 21:57
  • @random832 /sys/ is a virtual filesystem. It doesn't actually exist so it takes up no space. – Shadur-don't-feed-the-AI Apr 25 '14 at 06:58
  • @Shadur I have no idea what I was thinking when I wrote that. Maybe I thought the mount point directory on the root filesystem would be counted somehow. – Random832 Apr 25 '14 at 15:56
  • @Random832 You probably forgot that it was a mounted file system and not a directory; it's an easy mistake to make, seeing as that's an entirely *nix-flavour-specific thing. – wizzwizz4 Nov 28 '18 at 21:58
4

The inode table (as well as a few very much smaller things) is included in the used space. It looks like you have about 18GB of inodes. That's around 6% of the space, which is in the expected ballpark for ext2/ext3/ext4 (filesystems that don't have an inode table are likely to have larger directory entries if nothing else). You can find the precise size used for inodes by running tune2fs -l /dev/mapper/VolGroup00-LogVol00, e.g. here are the relevant lines for one of my 20GB ext3 filesystems:

Inode count:              2622368
Inode size:               128

That partition has 2622368×128 B ≈ 320 MB of inodes.

Additional note: the way you've invoked du, you'll see spaced used by every file even on remote mounts and other non-directly-disked-backed filesystems. Run du -x / to see just what's stored on the root filesystem.

Gilles 'SO- stop being evil'
  • 829,060