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
Improve this question
4
  • So... you expect us to sum the values. Please use du -smc /* | sort -n -r vs. df -m instead (also fixes the broken sort)
    – sehe
    May 26, 2011 at 8:12
  • Instead of sorting numerically, you should treat those numbers as human readable numbers: du --max-depth=1 -h / | sort -hr. This will put "75G /" first.
    – user26112
    May 30, 2013 at 10:35
  • @casey we want to do this the other way around, maybe. see meta.unix.stackexchange.com/a/2721/29146
    – strugee
    Feb 2, 2014 at 22:37
  • Useful info here: Why are there so many different ways to measure disk usage?
    – terdon ♦
    Mar 19, 2014 at 4:34

2 Answers 2

Reset to default
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.

Improve this answer
8
  • 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, 2011 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, 2011 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, 2011 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, 2011 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, 2011 at 21:57
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.

Improve this answer