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> Howeve
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
> 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
> >> ... 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 payi
... 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
> > 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 R
Darren Dunham wrote:
Also, even if it could read the data from a subset of the disks, isn't
it a feature that every read is also verifying the parity for
correctness/silent corruption?
It doesn't -- we only read the data, not the parity. (See line 708 of
vdev_raidz.c.) The parity is che
Darren Dunham wrote:
Also, even if it could read the data from a subset of the disks, isn't
it a feature that every read is also verifying the parity for
correctness/silent corruption?
It doesn't -- we only read the data, not the parity. (See line 708 of
vdev_raidz.c.) The parity is checked on
> > Also, even if it could read the data from a subset of the disks, isn't
> > it a feature that every read is also verifying the parity for
> > correctness/silent corruption?
>
> It doesn't -- we only read the data, not the parity. (See line 708 of
> vdev_raidz.c.) The parity is checked only wh
> 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 checksu
10 matches
Mail list logo
