On a customer's machine running SuSE 9.2, the size of the occupied space on the harddisk is reported incorrectly by "df -h". After we noticed the problem, I rebooted the machine and had it checked by "e2fsck" (check forced with "tune2fs -C 40", we are not on location). Right after the reboot I proceeded as follows, but I could not find any information about the cause, and the problem is still there - see below. That the value reported by "du -shx" is close to the correct one was verified by copying the data to an identical partition on a second harddisk: On this disk "du" and "df" both reported a size of about 4 GB, and not 7.6G, which is completely off the mark. # df -h / Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.6G 7.0G 216M 98% / # du -shx / 4.2G / # find / -xdev | wc -l 161021 # tune2fs -l /dev/sda1 tune2fs 1.35 (28-Feb-2004) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: a3f40d6f-51be-448b-bf71-76292772fea0 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal filetype needs_recovery sparse_super Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 1005888 Block count: 2010125 Reserved block count: 100506 Free blocks: 155746 Free inodes: 744793 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16224 Inode blocks per group: 507 Filesystem created: Sat Nov 5 19:00:05 2005 Last mount time: Mon Jan 30 13:28:19 2006 Last write time: Mon Jan 30 13:28:19 2006 Mount count: 1 Maximum mount count: 39 Last checked: Mon Jan 30 13:28:19 2006 Check interval: 15552000 (6 months) Next check after: Sat Jul 29 14:28:19 2006 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 First orphan inode: 357173 Default directory hash: tea Directory Hash Seed: 59ce6d12-990c-40ad-8268-212ae9bb8291 Journal backup: inode blocks Later we also tried out the following commands - apparently sparse files or unlinked files are not to blame: # lsof -s | grep deleted isam 6354 david 0r REG 8,1 55 357173 /tmp/sh-thd-1138650835 (deleted) vmware-vm 15452 arzt 48u REG 8,1 11948032 357177 /tmp/ram0 (deleted) # df --sync -h / Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.6G 7.0G 212M 98% / # du -shx --apparent-size / 3.9G . Any idea what may be the cause of the problem? -- Dipl.-Phys. Felix E. Klee Email: fk at linuxburg.de (work), felix.klee at inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15A, 76135 Karlsruhe, Germany
On Jan 30, 2006 19:38 +0100, Felix E. Klee wrote:> On a customer's machine running SuSE 9.2, the size of the occupied space on > the harddisk is reported incorrectly by "df -h". > > # df -h / > Filesystem Size Used Avail Use% Mounted on > /dev/sda1 7.6G 7.0G 216M 98% / > # du -shx / > 4.2G / > # find / -xdev | wc -l > 161021> # tune2fs -l /dev/sda1 > tune2fs 1.35 (28-Feb-2004) > Inode count: 1005888 > Block count: 2010125 > Reserved block count: 100506 > Free blocks: 155746 > Free inodes: 744793 > First orphan inode: 357173The "find | wc -l" definitely does not agree with the superblock info. That reports (1005888 - 744793 = 261095) in use inodes, not 161021. If those numbers agreed, I'd suspect some space leakage (though not after an e2fsck run). With 2.6 kernels the ext3 superblock info does not get updated on disk, except at shutdown (though it would be nice to have this done at, say, statfs time). There are no EAs consuming blocks (this would be 4kB per file, so 1GB in total for 250k files).> Later we also tried out the following commands - apparently sparse files or > unlinked files are not to blame: > > # lsof -s | grep deleted > vmware-vm 15452 arzt 48u REG 8,1 11948032 > 357177 /tmp/ram0 (deleted) > isam 6354 david 0r REG 8,1 55 > 357173 /tmp/sh-thd-1138650835 (deleted)This is also the file shown in the orphan inode list, so at least it is consistent. I also wouldn't expect files to be orphaned after e2fsck. The other thing you can do is run "dumpe2fs /dev/sda1" to see what the block group descriptors report for free blocks/inodes. You'd need some scripting to add this up, but fairly easy. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.