Nicolas Williams writes: > On Tue, Jan 30, 2007 at 06:32:14PM +0100, Roch - PAE wrote: > > > The only benefit of using a HW RAID controller with ZFS is that it > > > reduces the I/O that the host needs to do, but the trade off is that ZFS > > > cannot do combinatorial parity reconstruction so that it could only > > > detect errors, not correct them. It would be cool if the host could > > > offload the RAID I/O to a HW controller but still be able to read the > > > individual stripes to perform combinatorial parity reconstruction. > > > > right but in this situation, if the "cosmic ray / bit flip" hits on the > > way to the controller, the array will store wrong data and > > we will not be able to reconstruct the correct block. > > > > So having multiple I/Os here improves the time to data > > loss metric. > > You missed my point. Assume _new_ RAID HW that allows the host to read > the individual stripes. The ZFS could offload I/O to the RAID HW but, > when a checksum fails to validate on read, THEN go read the individual > stripes and parity and do the combinatorial reconstruction as if the > RAID HW didn't exist. > > I don't believe such RAID HW exists, therefore the point is moot. But > if such HW ever comes along... > > Nico > --
I think I got the point. Mine was that if the data travels a single time toward the storage and is corrupted along the way then there will be no hope of recovering it since the array was given bad data. Having the data travel twice is a benefit for MTTDL. -r _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
