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) Commented 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. Commented 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 Commented Feb 2, 2014 at 22:37
  • Useful info here: Why are there so many different ways to measure disk usage? Commented 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. Commented 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) Commented 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. Commented May 26, 2011 at 21:56
  • 1
    @jmtd: A high-churn folder would grow to the maximum-ever size and then stop. Commented 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. Commented 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