Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Why are there differences between the outputs of the df and du commands?

Why they are not accurate in output?

# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 1012M 394M 567M 42% /
/dev/sda2 99M 47M 48M 50% /boot
/dev/sda8 9.9G 1.5G 7.9G 16% /home
none 1004M 0 1004M 0% /dev/shm
/dev/sda9 347G 93G 236G 29% /srv
/dev/sda11 2.0G 81M 1.8G 5% /tmp
/dev/sda10 4.0G 1.3G 2.6G 33% /usr
/dev/sda6 4.0G 2.1G 1.8G 55% /usr/local
/dev/sda5 20G 19G 0 100% /var

However, if I do a du -sh /var it reports that only 4.6G are being used:

# du -sh /var
4.6G /var
share|improve this question

migrated from May 27 '11 at 20:50

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

The standard cause for this is some user process keeping a deleted file open. When this happens, the space is not visible via ‘du’, since the file is no longer visible in the directory tree. However, the space is still used by the file until it is deallocated, and that can only happen once the last process which has the file open either closes its file descriptor to the file, or the process exits. You can use the lsof program to try to find which process is keeping an open file. Usually it’s some log file, or some large data base file which gets rotated out, but some older process are still keeping the log file open.

source : ‘df’ command VS ‘du’ command

share|improve this answer

Ttry this:
If the files are deleted (by rm command) while they are being opened or used by a Linux program / process, the evil of "open file descriptor" problem arises and confuse the Linux file system on reporting the real figure of used disk space or free disk space available.

In order to resolve the fake "disk space full" problem, i.e. to reclaim "used disk space", you need to kill or terminate the "defunct process" - in this case, the rm command that turns to be defunct process while the files are being used.

Once these defunct processes are terminated, the "open file descriptor" problem will be resolved, and both the du and df commands will agree to report the real file system used disk space or free disk space!

How to find out and terminate or kill the defunct processes that cause open file descriptor problem, in order to resolve the difference of used disk space in du and df command?

For this particular scenario, the lsof command (list open file command) is great to show light:

#lsof | grep "deleted"

and look for Linux process ID in second column of the lsof command output. The seventh column is the size of file being "deleted" (but not success and turns out to be defunct process).

Now, you'll just need to kill the Linux process IDs to see the correct ouput of DU and DF, Use following command to kill the Process IDs

#lsof | grep "deleted" | awk '{print $2}' | xargs kill -9

Now verify the disk usage by both commands; you should not get the difference.

share|improve this answer
Here's a slightly less dangerous listing command: lsof | grep "deleted" | awk '{print $2}' | uniq | sort | xargs ps -p – Joe Casadonte Mar 20 '14 at 17:52

This doesn't apply in your case, but in general it's important to remember the -x flag to du. Otherwise it might go into other mounted filesystems and certainly won't match df output, which by default is per-filesystem.

share|improve this answer

You must log in to answer this question.