Does it not store a separate checksum for a parity block? If so, it
should not even need to recalculate the parity: assuming checksums match
for all data and parity blocks, the data is good. 

I could understand
why it would not store a checksum for a parity block. It is not really
necessary: Parity is only used to reconstruct a corrupted block, so you
can reconstruct the block and verify the data checksum. But I can also
see why they would: Simplified logic, faster identification of corrupt
parity blocks (more usefull for RAIDZ2 and greater), and the general
principal that all blocks are checksummed. 

If this was the case, it
should mean that RAIDZ scub is faster than mirror scrub, which I don't
think it is. So this post is probably redundant (pun intended) 

2012-10-25 20:46, Jim Klimov wrote: 

> 2012-10-25 21:17, Timothy
Coalson wrote:
>> On Thu, Oct 25, 2012 at 7:35 AM, Jim Klimov
< [1]>> wrote: If scrubbing works the
way we "logically" expect it to, it should enforce validation of such
combinations for each read of each copy of a block, in order to ensure
that parity sectors are intact and can be used for data recovery if a
plain sector fails. Likely, raidzN scrubs should show as
compute-intensive tasks compared to similar mirror scrubs. It should
only be as compute intensive as writes - it can read the userdata and
parity sectors, ensure the userdata checksum matches (reconstruct and do
a fresh write in the rare cases it is not), and then recalculate the
parity sectors from the verified user sectors, and compare them to the
parity sectors it actually read.
> Hmmm, that's another way to skin the
cat, and it makes more sense ;) //Jim
_______________________________________________ zfs-discuss mailing list [2] [3]

zfs-discuss mailing list

Reply via email to