Ext3 users - Jul 2004 - file size and actually blocks do not match

I have a disk where serveral files have a file size that is much bigger
then the space they actually use.  THe file size is bogus. In the example
below, the size is reported as 4.2MB but the file is really supposed to be
on 116K which is true accoring to du and the block list from debugfs.

However, doing a 'cat |wc' file actually gives me 4.2MB bytes. Where are
those extra bytes coming from since the inode certainly does not have the
blocks!

Doing a fcsk does not fix the situation as shown below.

This is on a RH7.3 machine running a 2.4.20 kernel


root at 1[bh-sm5-per-006]# debugfs /dev/hda4
debugfs 1.35-WIP (31-Jan-2004)
debugfs:  stat
users/greve/fbirn-hp-fsfast/dunc-data/dunc-101.1/bold/bh-sm5-per-006/beta_008.bfloat
Inode: 5980769   Type: regular    Mode:  0777   Flags: 0x0   Generation: 
4199683
297
User:  5652   Group:  5652   Size: 4243456
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 232
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x406066ae -- Tue Mar 23 11:32:46 2004
atime: 0x40e5b58c -- Fri Jul  2 15:20:44 2004
mtime: 0x406066ae -- Tue Mar 23 11:32:46 2004
BLOCKS:
(0):19431070, (1-2):19431076-19431077, (3):19431079, (4):19431130, 
(5):19431136,
 (6-11):24618332-24618337, (IND):24618338, (12-27):24618339-24618354
TOTAL: 29

debugfs:  quit

root at 1[/]# umount /mnt/greve/old/4

root at 1[/]# e2fsck -y /dev/hda4
e2fsck 1.35-WIP (31-Jan-2004)
/dev/hda4: clean, 1467459/18448384 files, 33585486/36871183 blocks (check 
after next mount)

root at 1[/]# e2fsck -y -f /dev/hda4
e2fsck 1.35-WIP (31-Jan-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hda4: 1467459/18448384 files (6.4% non-contiguous), 33585486/36871183 
blocks

root at 1[/]# mount /dev/hda4 /mnt/greve/old/4

root at 1[/]# debugfs /dev/hda4
debugfs 1.35-WIP (31-Jan-2004)
debugfs:  stat
users/greve/fbirn-hp-fsfast/dunc-data/dunc-101.1/bold/bh-sm5-per-006/beta_008.bfloat
Inode: 5980769   Type: regular    Mode:  0777   Flags: 0x0   Generation: 
4199683
297
User:  5652   Group:  5652   Size: 4243456
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 232
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x406066ae -- Tue Mar 23 11:32:46 2004
atime: 0x40e5b58c -- Fri Jul  2 15:20:44 2004
mtime: 0x406066ae -- Tue Mar 23 11:32:46 2004
BLOCKS:
(0):19431070, (1-2):19431076-19431077, (3):19431079, (4):19431130, 
(5):19431136,
 (6-11):24618332-24618337, (IND):24618338, (12-27):24618339-24618354
TOTAL: 29

debugfs:


-- 
---------------------------------------------------------------
Paul Raines                   email: raines at nmr.mgh.harvard.edu
MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging
149 (2301) 13th Street        Charlestown, MA 02129	USA

Paul Raines wrote:
> I have a disk where serveral files have a file size that is much bigger
> then the space they actually use.  THe file size is bogus. In the example
> below, the size is reported as 4.2MB but the file is really supposed to be
> on 116K which is true accoring to du and the block list from debugfs.
Sparse file?

$ dd if=/dev/zero of=testfile seek=1M count=1 bs=1024
1+0 records in
1+0 records out
$ ls -l testfile
-rw-r--r--    1 <me>    <me>    1073742848 Jul  2 19:04 testfile
$ du -h testfile
12K testfile
$ wc testfile
       0       0 1073742848 testfile
$

This file contains 1 gig of empty space, then 1K of zeros.  The gig of
empty space reads as zeros to most programs (including wc), but the
zeros aren't actually stored on disk, because they've never been written
to.  That's why it's sparse.

The files are not (at least supposed to be) sparse files.  
They are a format called bfloat.  There are about 1000 of
them in that directory and suddenly 8 seem corrupt with
the too big size.

-- 
---------------------------------------------------------------
Paul Raines                   email: raines at nmr.mgh.harvard.edu
MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging
149 (2301) 13th Street        Charlestown, MA 02129	USA