On 7/26/06, Paul Clements <paul.clements@xxxxxxxxxxxx> wrote:
Mike Snitzer wrote: > I tracked down the thread you referenced and these posts (by you) > seems to summarize things well: > http://marc.theaimsgroup.com/?l=linux-raid&m=111116563016418&w=2 > http://marc.theaimsgroup.com/?l=linux-raid&m=111117515400864&w=2 > > But for clarity's sake, could you elaborate on the negative > implications of not merging the bitmaps on the secondary server? Will > the previous primary's dirty blocks get dropped on the floor because > the secondary (now the primary) doesn't have awareness of the previous > primary's dirty blocks once it activates the raid1? Right. At the time of the failover, there were (probably) blocks that were out of sync between the primary and secondary.
OK, so now that I understand the need to merge the bitmaps... the various scenarios that create this (potential) inconsistency are still unclear to me when you consider the different flavors of raid1. Is this inconsistency only possible if using async (aka write-behind) raid1? If not, how would this difference in committed blocks occur with normal (sync) raid1 given MD's endio acknowledges writes after they are submitted to all raid members? Is it merely that the bitmap is left with dangling bits set that don't reflect reality (blocks weren't actually changed anywhere) when a crash occurs? Is there real potential for inconsistent data on disk(s) when using sync raid1 (does having an nbd member increase the likelihood)? regards, Mike - 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
