>>>>> "ca" == Carsten Aulbert <carsten.aulb...@aei.mpg.de> writes: >>>>> "ok" == Orvar Korvar <knatte_fnatte_tja...@yahoo.com> writes:
ca> (using hdparm's utility makebadsector)
I haven't used that before, but it sounds like what you did may give
the RAID layer some extra information. If one of the disks reports
``read error---I have no idea what's stored in that sector,'' then
RAID5/6 knows which disk is wrong because the disk confessed. If all
the disks successfully return data, but one returns the wrong data,
RAID5/6 has to determine the wrong disk by math, not by device driver
error returns.
I don't think RAID6 reads whole stripes, so even if the dual parity
has some theoretical/implemented ability to heal single-disk silent
corruption, it'd do this healing only during some scrub-like
procedure, not during normal read. The benefit is better seek
bandwidth than raidz. If the corruption is not silent (the disk
returns an error) then it could use the hypothetical magical
single-disk healing ability during normal read too.
ca> powered it up and ran a volume check and the controller did
ca> indeed find the corrupted sector
sooo... (1) make your corrupt sector with dd rather than hdparm, like
dd if=/dev/zero of=/dev/disk bs=512 count=1 seek=12345 conv=notrunc,
and (2) check for the corrupt sector by reading the disk
normally---either make sure the corrupt sector is inside a checksummed
file like a tar or gz and use tar t or gzip -t, or use dd
if=/dev/raidvol | md5sum before and after corrupting, something like
that, NOT a ``volume check''. Make both 1, 2 changes and I think the
corruption will get through. Make only the first change but not the
second, and you can look for this hypothetical math-based healing
ability you're saying RAID6 has from having more parity than it needs
for the situation.
ok> "upon writing data to disc, ZFS reads it back and compares to
ok> the data in RAM and corrects it otherwise".
I don't think it does read-after-write. That'd be really slow.
The thing I don't like about the checksums is that they trigger for
things other than bad disks, like if your machine loses power during a
resilver, or other corner cases and bugs. I think the Netapp
block-level RAID-layer checksums don't trigger for as many other
reasons as the ZFS filesystem-level checksums, so chasing problems is
easier.
The good thing is that they are probably helping survive the corner
cases and bugs, too.
pgpn4n8gOCDNs.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
