Spontaneous development of supremely large files on different ext3 filesystems

Stephen Samuel darkonc at gmail.com
Wed Sep 12 07:30:59 UTC 2007

It's not clear where the error occured. It may actually be that there
was a multi-bit error, and that it was incorrectly  'fixed'. It's also
still possible that The  spurious bit was flipped somewhere in
software -- which wouldn'b be picked up by the RAID parity, because
the RAID parity took that flipped bit into account.

If you have hardware raid, then it's possible that the bit was flipped
during or after transmission, but before parity was calculated..

Check for disk errors in your log files.

Generically speaking, I'd be inclined to believe that the lower bits
in the large file size are actually the precise size of the file...
Check if the size minus the high-order flipped bit is consistent with
a logical place to end the file.

Note that the bit could have been flipped when a nearby inode (on the
same disk/RAID  block) was updated   The block was read, modified and
re-written and during that process, the bit could have been  magically

On 9/12/07, Maurice Volaski <mvolaski at aecom.yu.edu> wrote:
> >  > (( Note that  both of the 'old' file sizes are multiples of 8K ))
> >
> >That is because e2fsck doesn't know the correct size, so just uses
> >the end of the last valid block (it isn't possible to have a "hole"
> >at the end of the file).
> It looks like more than 1 bit was different and if I understand this
> correctly, those other bit changes are the result of this after fact
> padding by e2fsck.
> >The filesize is basically the same, except for the addition of a stray
> >bit, way off in left field.   (( Note that  both of the 'old' file
> >Yes, it looks like single-bit corruption of some kind.
> So does this imply a spontaneous bit flip on a platter? Shouldn't
> that have been picked by the RAID and twice because there is dual
> parity (RAID 6)?
> --
> Maurice Volaski, mvolaski at aecom.yu.edu
> Computing Support, Rose F. Kennedy Center
> Albert Einstein College of Medicine of Yeshiva University

Stephen Samuel http://www.bcgreen.com

More information about the Ext3-users mailing list