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

My system is CentOS 6 x86_64 with root partition formatted as ext4. df reports around 3Gb as used space:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/md1              20158260   3433724  15700540  18% /

but du -sm -x / claims less than a single Gb is used actually:

[root@xxxx ~]# du -sm -x /
948     /

I wonder what is going on here. Usage numbers changed right after reboot. The filesystem claims it's clean, no errors in logs. I found this, but it did not explain a root of the problem. Should I just reformat the partition? Is there any way to track down this extra usage?

I also did the following to check that I don't have any data hidden from du by mounts on top of non-empty mountpoints:

[root@xxxx ~]# mount -o bind / /mnt/root
[root@xxxx ~]# du -sm /mnt/root/
949     /mnt/root/
[root@xxxx ~]#

No, that's not my case.

share|improve this question
possible duplicate of du vs. df difference – Iain Sep 13 '11 at 6:52
@Iain Checked the link, thank you. The only relevant thing seems to be a lost mount problem (and the accepted solution on this link). I do not have small files and I have a similar box with the same partition layout and same files on / but it does not report 3G of used space. And I do not have a lost mount problem, but this is a subject to double check. – Alex Sep 13 '11 at 7:37
@Iain Checked the lost mount problem, no, that's not it. I will update my question. – Alex Sep 13 '11 at 9:28
up vote 6 down vote accepted

The first thing I would think is that you have deleted files. Using lsof -n | grep deleted will help you. Does the output of that command shows you some files? (maybe you have a huge log file still being written). If you have files opened by a process (a syslogger or something like Apache web server) that are being written into they may be using a lot of disk space and the easies way will be restarting the process owning of those deleted files.

If there aren't any deleted files, could you paste the output of running tune2fs -l ?

share|improve this answer
Yeah, that was it, thank you! Several qemu .save files, pretty huge. – Alex Sep 13 '11 at 10:07
Before I even got half way through your question, I was guessing this was the most the most likely cause. It actually makes for a great Unix interview question: "du says I have free space, but I get no space left on device errors. What's going on?" lsof is your friend in many situations. :) – Larold Sep 14 '11 at 5:09
Oh - one other thing to keep in mind. I know ext3 does this, and ext4 probably does as well. There's usually a small percentage of "reserved" space left for the root user. This is in case the filesystem fills up with user data - it still leaves room for the root user to run commands safely, go in, and fix the problem. If the reserved space fills up, then you're SOL and just need to delete stuff - very few other commands will work reliably when you're cd'ed into the full filesystem. I recall that 'tune2fs -m' sets the percentage. Not directly related, but a useful tidbit. – Larold Sep 14 '11 at 5:12

Force a filesystem check on next reboot. You may have unrecovered inodes that are holding data.

# touch /forcefsck  # Run as root, then reboot.


share|improve this answer

Ext3/4 can use up to 400MB for the journal file, which you can not see. The size of the journal size is automatically scaled with the size of the filesystem created or can be manually specified at filesystem creation time.

share|improve this answer
According to dumpe2fs, journal is only 128M on my system, and I am trying to reclaim more than 2G of space, as you can see. – Alex Sep 13 '11 at 7:28

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.