Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

This question already has an answer here:

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
share|improve this question

migrated from stackoverflow.com May 26 '11 at 12:51

This question came from our site for professional and enthusiast programmers.

marked as duplicate by Anthon, jasonwryan, rahmu, slm, Renan Feb 3 at 0:47

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
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 '11 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. –  paraxor May 30 '13 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 at 22:37
    

2 Answers 2

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.

share|improve this answer

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 system has 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's processes uses files to everything (I'm simplifying) i.e. writing to log files, there could be also open file descriptor problem in this case causing different du and df outputs.

share|improve this answer
    
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 May 26 '11 at 21:56
    
@jmtd: A high-churn folder would grow to the maximum-ever size and then stop. –  Gilles 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 May 26 '11 at 21:57