Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. 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 small ext3 / partition on a 2T drive which appears to have a discrepancy in its free space. How can I determine what is causing it and how it can be fixed.

After trying everything I could think of, I forced a fsck on boot which didn't have any affect.

I have other systems configured identically which don't exhibit this condition.

# df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.7G  8.9G  318M  97% /

# du -shx --max-depth 1 /
5.2G    /

# lsof | awk 'BEGIN {t=0} /(deleted)/ {t+=$7} END {print t}'

# tune4fs -l /dev/sda1 | grep -E 'state|Free|Reserve|size|Inode'
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem state:         clean
Inode count:              2621440
Reserved block count:     131029
Free blocks:              212317
Free inodes:              2487281
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      639
Inodes per group:         32768
Inode blocks per group:   1024
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
Inode size:               128


fsck says the partition is 2% non-contiguous.

For comparison to du above (sparseness):

# du -hxs --apparent-size /
4.9G    /
share|improve this question
See How to understand what's taking up space? for some tools to find where the space is. – Caleb Aug 25 '11 at 23:31
up vote 3 down vote accepted

The one explanation that comes to mind is that you have stuff hidden behind a mount point, out of the reach of du.

On Linux, you can make a bind mount of the root filesystem so as to be able to see all of it on a different mount point. Then take a closer look at the stuff that's hidden by mount points in the original view.

mkdir /root/root-rebound
mount -o bind / /root/root-rebound
du -sc $(df -P | awk 'NR>2 {print "/root/root-rebound" $6}')
share|improve this answer
Bingo! Thanks! This is something I know about, but I completely failed to consider it. This is the third mistake I've made this week! – Dennis Williamson Aug 27 '11 at 13:32

Have you looked at the fragmentation at all? The only way I know that du and df can disagree(besides the deleted part you already ruled out) is overhead, and that usually comes from a bunch of fragmented files(where du would report a small amount, but because of the number of extents the files are really big on disk, and as seen by df).

This tool can show you how bad the fragmentation is on ext3 files:


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.