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. Now, after you've failed over to the secondary, you've got to overwrite those blocks with data from the secondary in order to make the primary disk consistent again. This requires that either you do a full resync from secondary to primary (if you don't know what differs), or you merge the two bitmaps and resync just that data.
I took more time to read the later posts in the original thread; that coupled with your detailed response has helped a lot. thanks.
> Also, what is the interface one should use to collect dirty bits from > the primary's bitmap? Whatever you'd like. scp the bitmap file over or collect the ranges into a file and scp that over, or something similar.
OK, so regardless of whether you are using an external or internal bitmap; how does one collect the ranges from an array's bitmap? Generally speaking I think others would have the same (naive) question given that we need to know what to use as input for the sysfs interface you've kindly provided. If it is left as an exercise to the user that is fine; I'd imagine neilb will get our backs with a nifty new mdadm flag if need be. thanks again, 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
