Re: Erroneous data with ext2fs

Ingo Molnar (
Sun, 9 Mar 1997 21:41:59 +0100 (MET)

> 525807650 41 0
> 525807651 10 0
> As you may notice, from 525807618 on, it looks like a 4-byte integer in
> lsb order which counts up.

the 1024 bytes boundary is at 525807616. This means the following integer
is counted up:

0 2 200 206
0 2 200 207
0 2 200 208

additionally, your analysis shows that errors only occur after ~480M data
written, and >never< before. At first sight this rules out ext2fs as an
error source (but see below). Your device is 630M large.

as the corrupted data has the above regularity, block buffer corruption
can be ruled out too.

Back to the ext2fs issue, AFAIK there is only one physical ext2fs metadata
that has the above structure, namely 'inode data double indirection
blocks'. Assuming that the corrupted data is a double indirection block
and converting the above number back into block number leads to block
#182478 [plausible]. The erroneous block is ~ 525807616/1024=513484.

Such large distance between a block and a (possibly related) inode
metadata block is quite strange. [default ext2fs behaviour for your
sequentially created zero file is allocating blocks in a continous manner,
and adding one indirection block every ... 256K ]. Thus for a 'correct
file', the indirection block containing 182478,182479,182480,... should be
near block 182478 +- 256K, but not block ~513484.

i dont understand how this metadata block could get up there. Maybe people
with more ext2fs knowledge know the answer.

-- mingo