2012-10-26 12:29, Karl Wagner wrote:
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.
No, for the on-disk sector allocation over M disks, zfs raidzN writes N parity sectors and up to M-N data sectors (may be less for small blocks and tails of blocks) for which that parity is, then repeats the process until it runs out of userdata sectors in the to-write buffer. Overall the parity and data sectors make up the on-disk block's contents. Matching the contents (plain userdata or permutations with parities) to the expected checksum of the logical block (of userdata) is what guarantees that the block was not corrupted - or that corruption was detected and repaired (or not). I am not sure how far permutations go however - does it try to repair per-stripe or per-column? If it tries hard, there are quite many combinations to try for a 128Kb block spread over 512b sectors in a raidz3 set ;)
I could understand why it would not store a checksum for a parity block.
To summarize, parities are not separate blocks. They are additional sectors prepended (and intermixed with) sectors of userdata, all together saved as the on-disk block. //Jim _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
