David Lethe wrote: > Hmm - I wonder if things like ddrescue could work with the md bitmaps to > improve > this situation? > Is this related to David Lethe's recent request? > > ----------- > No, we are trying two different approaches. > In my situation, I already know that the data is munged on a particular > block, so the solution is to calculate the correct data from surviving > parity, and just write the new value. There is no reason to worry about > md bitmaps, or even whether or not there are 0x00 holes. I think we (or I) may be talking about the same thing? Consider an array sd[abcde] and a badblock (42) on sdb followed by a badblock elsewhere (142) on sdc. I would like to ddrescue sdb to sdb' and sdc to sdc' (leaving holes) block 42 should be recovered from sd[acde] to sdb' block 142 should be recovered from sd[abde] to sdc' The idea was to possibly tristate the bitmap clean/dirty/corrupt. If md gets a read/write error then it marks the block corrupt; alternatively we could use the output from ddrescue to identify corrupt blocks that md may not have seen. I wondered whether each block actually needed to record the event it was last updated with. I haven't thought through the various failure cases but... > I am not trying to fix a problem such as a rebuild gone bad or an > intermittent disk failure that put the md array in a partially synced, > and totally confused state. No, me neither... > My desire is to limit damage before a full disk recovery needs to be > performed, by insuring that there are no double-errors that will make > stripe-level recovery impossible (assuming they aren't using RAID6). > For that I need a mechanism to repair a stripe given a physical disk and > offset. There is no completely failed disk to contend with, merely a > block of bad data that will repair itself once I issue a simple write > command. (trick, of course, is to figure out exactly what & where to > right it and deal with potential locking issues relating to file > system). I think I'm describing that too. If you simplify my case to a single badblock do we meet? David -- 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
