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