Just to illustrate the case. This is just how I got that it works,
please pardon the amateur level on algorithm details here.
With the Fletcher checksumming, say that you have the Fletcher checksum
in a tree structure of two levels: One at the disk root, one for every
100MB of data on the disk.
When you read any given sector on the disk, it will be checked for
consistency with those two checksums, and if there's a failure, fread()
will fail.
Example: I write to sector/block X which is at offset 125MB.
That means the root checksum and the 100MB-200MB branch checksums are
updated.
I now shut down and start my machine again, and now block/sector X
changed mapping with some random block/sector Y located at offset
1234MB.
Consequently, any fread() both of sector X and of sector Y will fail
deterministically, because both the root checksum and the 100-200MB
checksum and the 1200-1300MB checksum checks would fail.
Reading other parts of the disk would work though.
On 2015-12-02 03:31, Tinker wrote:
Hi Karel,
Glad to talk to you.
Why the extra IO expense?
About the Fletcher vs not Fletcher thing, can you please explain to me
what happens in a setup where I have one single disk with one single
RAID partition on it using your disciple, and..
1) I write a sector/block on some position X
2) My disk's allocation table gets messed up so it's moved to another
random position Y
3) I read sector/block on position Y
4) Also I read sector/block on position X
