Hi Jakob, > To me it has been fairly common. I can confirm that, I've also seen this a few times. > But what workaround would you put into the MD code ? Just > write a zero block > to the bad sector, and "gracefully" ignore the bad block (leaving the > filesystem with a zeroed out hole) ? No, the correct action > is to kick the disk (IMO). As long as we're talking about raid5 or raid1, you should still be able to get the correct data from the raid device, use this to try a rewrite after a read error. if the write works and a read afterwards works as well => don't kick the disk. Having this functionality could be worthwile; of course if this triggers, it should write a warning to syslog. > I've been thinking about doing things like nightly "scans" of > the underlying disks - but that kind of code is much easier done in > userspace (where it belongs). Then, you'd have a failed disk in > the morning, which is better than suddenly having a failed disk in > a RAID-5 and then losing the entire array when number two disk > fails during the re-sync. Definitely better than a failure at a later time.. still, having some sort of "autorecover" funtion to allow disk-internal sector remapping to fix bad sectors could be really nice. Sometimes it needn't actually be a real bad sector - if the system went down while a write was in progress (power failure), there could easily be a partialy written sector that would trigger a read/crc error, but works fine once it's overwritten with valid data. Bye, Martin - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
