On 2016-02-01 16:29, Janne Johansson wrote:
2016-01-31 9:24 GMT+01:00 Tinker <[email protected]>:
Q1:
My most important question to you is, the DATA that you CHECKSUM, do
you
include the SECTOR NUMBER (or other disk location info) of that data
into
your checksum function's inputs, so if the underlying storage's
storage
mapping table breaks down or by other reason disk WRITE:s go to the
WRONG
place, then when READ later on, those READS will FAIL?
Whenever any underlying storage does migrations, it would never change
the
OS view of the sector number, all filesystems (raid or not) would break
if
that happened.
Janne (and Karel),
The reason I suggested the location info e.g. sector number to be
included in the checksum calculation's input data, is that it's a real
risk that a disk's logical-sector-to-physical-sector-mapping table
breaks down, either because of physical failure, or because of firmware
errors in disk controller or disk, or because of OS bugs, memory bugs,
driver bugs, you name it.
While I agree that within RAID1C the probability ridiculously small,
that such a failure would happen so that a certain sector X's location
would be corrupted, *and* that its checksum in the checksums zone on the
disk would be corrupted in a way symmetric with the first corruption so
that the checksum checks not would catch the problem also, then still on
a level of (mathemathical/system) symmetry it does make a sense that the
checksum calculation uses the data location as input also.
ZFS does this to guarantee that the data read is the data that really
belongs there.
And I guess we're talking about in the range 50-100 extra CPU cycles per
sector access to deliver this, and no extra storage need, so my
spontaneous feel about this is that it probably could be implemented on
a "why-not" basis -
What do you say?
Tinker
