-----Original Message----- From: Keld Jørn Simonsen <keld@xxxxxxxx> Subj: Re: Distributed spares Date: Tue Oct 14, 2008 8:06 am Size: 1K To: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx> cc: "Billy Crook" <billycrook@xxxxxxxxx>; "Justin Piszcz" <jpiszcz@xxxxxxxxxxxxxxx>; "Bill Davidsen" <davidsen@xxxxxxx>; "Neil Brown" <neilb@xxxxxxx>; "Linux RAID" <linux-raid@xxxxxxxxxxxxxxx> On Tue, Oct 14, 2008 at 06:12:29AM -0400, Martin K. Petersen wrote: > >>>>> "Keld" == Keld Jørn Simonsen <keld@xxxxxxxx> writes: > > Keld> I have also been thinking a little on this. My idea is that if > Keld> bit errors develop on disks, then there is first maybe one bit > Keld> error, and the crc check on the disk sectors then finds and > Keld> corrects these. > > Keld> If you rewrite such bit errors, then that bit error will be > Keld> corrected, and you prevent the one-bit error from developing to > Keld> a two-bit error that is not correctable by the CRC. > > I think you are assuming that disks are much simpler than they > actually are. > > A modern disk drive protects a 512-byte sector with a pretty strong > ECC that's capable of correcting errors up to ~50 bytes. Yes, that's > bytes. > > Also, many drive firmwares will internally keep track of problematic > media areas and rewrite or reallocate affected blocks. That includes > stuff like rewriting sectors that are susceptible to bleed due to > being adjacent to write hot spots. Good to know. Could yo tell me if this is actually true for normal state-of-the art SATA disks, or only true for more expensive disks? Do you have a good reference for it. best regards keld -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html read the manual for any disk drive... They go into error detection, correction recovery algorithms and capability in great detail. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html