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.


zfs-discuss mailing list

Reply via email to