On Jan 30, 2014, at 5:20 AM, "Samer, Michael (I/ET-83, extern)" <extern.michael.samer@xxxxxxx> wrote: > > * reading about TLER I believe I understood that the failing disks > are not necessarly broken, but the RAID thinks they are; does it mean > that I can still use the failing disks? For starters, make sure the SCSI command timer is increased to at least that of the drive timeout, there's a chance the drive might recover data before there's a read error. echo 120 >/sys/block/sdX/device/timeout This is per drive kernel setting. So you have to do this for each drive. It's also not persistent across reboots. If during your rebuild any two drives report a read error, then it's a problem. And the rebuild stops. In this case, you can find the affected drive(s) and sectors causing the read error from dmesg. Then on individual physical drives, do sector reads to locate the exact LBAs affected. If these are AF disks, don't forget for each bad 4096 byte sector, you'll get 8 LBA read errors. To fix it, you must write to all 8 LBAs. I'd avoid using bs=4096 to avoid confusion because that also changes any seek= value away from 512e based LBAs. Just keep it all 512 sector based, and just know you have to write out a count of at least 8 to fix each physical sector. Before doing this though, I'd report back if you're getting two UREs on a stripe and the rebuild fails. Someone else with more experience may help with which disk to choose. Obviously the above means destroying some data on disk, but it's better to zero a bad sector (which is lost anyway) rather than it producing a URE - this way you only get one URE for that stripe on the next rebuild. What data is corrupted as a result of this depends on what was located in those sectors, it has a decent chance of being free space if the array isn't full. Next most likely is some file data or metadata. And then less likely is file system metadata… once the rebuild is done, you'll run an fsck with -n, to see if there are file system problems and how major they are. You don't necessarily want to run an fsck that writes changes to the file system as a first step, it could write changes that hose the fs even though the array rebuild was successful. Anyway, cross that bridge when you come to it, but it's better to work slower and make as few changes as necessary if this is an array that you don't have a current backup for. Chris Murphy -- 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
