Hello Anton,
Saturday, January 6, 2007, 6:29:29 AM, you wrote:
It's not about the checksum but about how a fs block is stored in
raid-z[12] case - it's spread out to all non-parity disks so in order
to read one fs block you have to read from all disks except parity
disks.
ABR However, if we
Ah, that's a major misconception on my part then. I'd thought I'd read
that unlike any other RAID implementation, ZFS checked and verified
parity on normal data access.
That would be useless, and not provide anything extra.
I think it's useless if a (disk) block of data holding RAIDZ
... If the block checksums
show OK, then reading the parity for the corresponding data yields no
additional useful information.
It would yield useful information about the status of the parity
information on disk.
The read would be done because you're already paying the penalty for
reading all
... If the block checksums
show OK, then reading the parity for the corresponding data yields no
additional useful information.
It would yield useful information about the status of the parity
information on disk.
The read would be done because you're already paying the penalty for
It's not about the checksum but about how a fs block is stored in
raid-z[12] case - it's spread out to all non-parity disks so in order
to read one fs block you have to read from all disks except parity
disks.
However, if we didn't need to verify the checksum, we wouldn't
have to read the
Darren Dunham wrote:
That would be useless, and not provide anything extra.
I think it's useless if a (disk) block of data holding RAIDZ parity
never has silent corruption, or if scrubbing was a lightweight operation
that could be run often.
The problem is that you will still need to
What happens when a sub-block is missing (single disk failure)? Surely
it doesn't have to discard the entire checksum and simply trust the
remaining blocks?
The checksum is over the data, not the data+parity. So when a disk fails,
the data is first reconstructed, and then the block checksum
