----- "Martin Nilsson" <[EMAIL PROTECTED]> wrote: > That is what patrol read is intended to detect before it is a problem. > > In a RAID5 array the checksums are only used when reconstructing data, > > if you have a bad block in a checksum sector it will not be detected > until a drive have failed and you try to rebuild the array, > unfortunately at that time it is too late... > > Beware that OS software solutions like diskcheckd will not find this > as > it only reads the data, not the checksums, it must be done on the > controller.
This isn't really accurate. First of all, if the RAID controller isn't confirming checksums before giving the data to the OS, what is the checksum for exactly? It is supposed to be for detecting data corruption, so if the card isn't using the checksum, its kinda of useless. I know some RAID systems do fake their checksums, as they don't actually validate data against the checksums during normal reads because they don't have the processing power. I'd stay away from these type of systems (cough ... Blue Arc ... cough). Second, most RAID systems don't use their own checksums anymore. Netapp is quite famous for their ZCS (zone checksum) drives, and still uses a variation of this technology on their newer systems (which are using 512 sectors). But most RAID vendors just rely on the drives own error detection and correction systems (hamming code based usually, which is actually pretty solid). I'm pretty sure that that 3ware doesn't use any checksums. However, in this particular case, validating checksums would have been unhelpful, since the disk was unreadable. diskcheckd would have detected this issue. It would probably have prevented the problem, if it had been running previously. ZFS is also a good option. It has file level checksumming. ZFS never trusts the disks, and is super paranoid. And ZFS can do background scrubbing too. I can't wait for ZFS in FreeBSD 7, because ZFS in software is going to 10 x better than anything 3ware has. > Regards, > Martin Tom _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
