5

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}'
0

# 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

Edit:

fsck says the partition is 2% non-contiguous.

For comparison to du above (sparseness):

# du -hxs --apparent-size /
4.9G    /
Dennis Williamson
  • 6,680

2 Answers2

6

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}')
Gilles 'SO- stop being evil'
  • 829,060
  • 1
    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
0

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:

http://vleu.net/shake/

polynomial
  • 2,461
  • 20
  • 15