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@xxxxxxxxxxxx (work), felix.klee@xxxxxxx (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15A, 76135 Karlsruhe, Germany _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
