Server Fault is a question and answer site for system and network administrators. 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

I have a SCSI disk in a server (hardware Raid 1), 32G, ext3 filesytem. df tells me that the disk is 100% full. If I delete 1G this is correctly shown.

However, if I run a du -h -x / then du tells me that only 12G are used (I use -x because of some Samba mounts).

So my question is not about subtle differences between the du and df commands but about how I can find out what causes this huge difference?

I rebooted the machine for a fsck that went w/out errors. Should I run badblocks? lsof shows me no open deleted files, lost+found is empty and there is no obvious warn/err/fail statement in the messages file.

Feel free to ask for further details of the setup.

share|improve this question
This is very close to the question: linux - du vs. df difference ( The solution was files under a mount point as OldTroll answered. – Chris Ting May 30 '11 at 16:45
up vote 57 down vote accepted

Check for files on located under mount points. Frequently if you mount a directory (say a sambafs) onto a filesystem that already had a file or directories under it, you lose the ability to see those files, but they're still consuming space on the underlying disk. I've had file copies while in single user mode dump files into directories that I couldn't see except in single usermode (due to other directory systems being mounted on top of them).

share|improve this answer
Bingo! :-) Thanks. – initall May 31 '11 at 6:54

Just stumbled on this page when trying to track down an issue on a local server.

In my case the df -h and du -sh mismatched by about 50% of the hard disk size.

This was caused by apache (httpd) keeping large log files in memory which had been deleted from disk.

This was tracked down by running lsof | grep "/var" | grep deleted where /var was the partition I needed to clean up.

The output showed lines like this:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

The situation was then resolved by restarting apache (service httpd restart), and cleared up 2gb of disk space, by allowing the locks on deleted files to be cleared.

share|improve this answer
For me, the locks where not released even after I stopped the program (zombies?). I had to kill -9 'pid' to release the locks. eg: For your httpd it would have been kill -9 32617. – Micka Jun 17 '15 at 8:57

See what df -i says. It could be that you are out of inodes, which might happen if there are a large number of small files in that filesystem, which uses up all the available inodes without consuming all the available space.

share|improve this answer
The size of a file and the amount of space it takes on a filesystem are two separate things. The smaller the files tend to be, the bigger the discrepancy between them. If you write a script that sums up the sizes of files and compare it to the du -s of the same subtree, you're going to get a good idea if that's the case here. – Marcin May 30 '11 at 15:00

I agree with OldTroll's answer as the most probable cause for your "missing" space.

On Linux you can easily remount the whole root partition (or any other partition for that matter) to another place in you filesystem say /mnt for example, just issue a

mount -o bind / /mnt

then you can do a

du -h /mnt

and see what uses up your space.

Ps: sorry for adding a new answer and not a comment but I needed some formatting for this post to be readable.

share|improve this answer
Thanks so much for this tip. Allowed me to find and delete my large, "hidden" files without downtime! – choover Feb 28 '13 at 13:47
Thanks - this showed that docker was filling up my hard drive with diffs in /var/lib/docker/aufs/diff/ – naught101 Aug 5 '15 at 3:29

In my case this had to do with large deleted files. It was fairly painful to solve before I found this page, which set me on the correct path.

I finally solved the problem by using lsof | grep deleted, which showed me which program was holding two very large log files (totalling 5GB of my available 8GB root partition).

share|improve this answer
This answer makes me wonder why you are storing log files on the root partition, especially one that small... but to each their own, I suppose... – Michael Kjörling Nov 14 '14 at 18:47
I had a similar issue , I had restarted all the applications that were using the deleted file , I guess there was a zombie process still holding on to a large deleted file – user1965449 Dec 15 '15 at 2:37

Files that are open by a program do not actually go away (stop consuming disk space) when you delete them, they go away when the program closes them. A program might have a huge temporary file that you (and du) can't see. If it's a zombie program, you might need to reboot to clear those files.

share|improve this answer
OP said he'd rebooted the system and the problem persisted. – OldTroll May 30 '11 at 12:58
I had zombies that wouldn't release the locks on the files, I kill -9 'pid' them to release the locks and get the disk space back. – Micka Jun 17 '15 at 8:58

Try this to see if a dead/hung process is locked while still writing to the disk: lsof | grep "/mnt"

Then try killing off any PIDs which are stuck (especially look for lines ending in "(deleted"))

share|improve this answer
Thanks! I was able to find that the SFTP server process was holding the deleted file – lyomi Aug 30 '13 at 4:43

This is the easiest method I have found to date to find large files!

Here is a example if your root mount is full / (mount /root) Example:

cd / (so you are in root)

ls | xargs du -hs

Example Output:

 9.4M   bin
 63M    boot
 4.0K   cgroup
 680K   dev
 31M    etc
 6.3G   home
 313M   lib
 32M    lib64
 16K    lost+found
 61G    media
 4.0K   mnt
 113M   opt
 du: cannot access `proc/6102/task/6102/fd/4': No such file or directory
 0  proc
 19M    root
 840K   run
 19M    sbin
 4.0K   selinux
 4.0K   srv
 25G    store
 26M    tmp

then you would notice that store is large do a cd /store

and run again

ls | xargs du -hs

Example output: 
 109M   backup
 358M   fnb
 4.0G   iso
 8.0K   ks
 16K    lost+found
 47M    root
 11M    scripts
 79M    tmp
 21G    vms

in this case the vms directory is the space hog.

share|improve this answer
Why not using simpler tools like baobab? (see – Yvan May 5 '15 at 7:11

if the mounted disk is a shared folder on a windows machine, then it seems that df will show the size and disk use of the entire windows disk, but du will show only the part of the disk that you have access too. (and is mounted). so in this case the problem must be fixed on the windows machine.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.