On Fri, 3 Jun 2016, Brad Campbell wrote:
If we took the bad block list from the dd_rescue, and fed it to hdparm to create bad sectors in all those locations on the cloned disk, md would get a bad sector on read and attempt a recovery rather than returning zero, This would "in theory" cause a re-write of good data back to that disk and minimise the chance of data loss.
Why would you use dd_rescue on a drive unless you're doing it because you're getting UREs on your remaining component drives on your degraded RAID5 so it won't complete resync? That's at least the most common use-case for ddrescue I've seen in md-raid scenarios.
This might be a useful "last ditch" recovery method to allow you to bring up an array with a cloned disk and minimise data loss. On the other hand, lets say you are using it to bring up a RAID 5 with 2 failed disks. One completely dead and one that you managed to clone most of. When you extract the data from the running and degraded array, md will pass the read error up the stack when it encounters the bad sectors, allowing your copy or rsync session to log which files are affected as you backup the remaining contents rather than just return silently corrupted files.
This use case makes a lot more sense to me than the first one. Knowing what files are now bad would be very useful.
But wouldn't it be better to put the known errors in the new bad_blocks list in md that I believe is a fairly recent feature?
-- Mikael Abrahamsson email: swmike@xxxxxxxxx -- 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
