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) On 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 <jimkli...@cos.ru  jimkli...@cos.ru>> 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 email@example.com  http://mail.opensolaris.org/mailman/listinfo/zfs-discuss  Links: ------  mailto:jimkli...@cos.ru  mailto:firstname.lastname@example.org  http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________ zfs-discuss mailing list email@example.com http://mail.opensolaris.org/mailman/listinfo/zfs-discuss