On 10/07/2016 01:44 PM, Dark Penguin wrote: > On 07/10/16 19:52, Phil Turmel wrote: >> MD raid has no idea what is at any given sector. And with a >> near-infinite variety of layering choices, there's no way it's going to. >> That's why *you* have to do this. You trimmed my description of the >> only "easy option" actually trustable. > > I actually wanted to ask about that. Can you really ddrescue a drive > with a "hole" in it, re-add it and expect it to work?.. What happens if > you try to read from that "hole" again? And while I'm talking about > re-adding, when does it become impossible to "re-add" a drive?.. Yes, ddrescue replaces unreadable areas with zeroes. If those blocks were part of a file, then the file will have zeroes in it. But they might have been where an inode or dirent were stored, in which case you get orphaned data elsewhere. You need fsck to minimize that. ddrescue can provide a listing of the sectors it replaced so you can use filesystem forensic tools to pinpoint the problems (which file, etc). Note that all of the above are manual operations -- mdadm has no knowledge of the upper layers. None of the above uses --re-add. Just assembly or forced assembly. Re-add is only to return a kicked drive to a *functional* array when the failure reason isn't really the drive. (Controller, cable, power supply, etc.) And re-add is only helpful if the array members have write-intent bitmaps so MD can figure out which parts of the re-added disk are out of date. Re-add can be used if a drive is kicked for timeout mismatch, but is only helpful if the mismatch is addressed first. Phil -- 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
