Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Feb 02, 2012 at 03:11:44PM +0100, Felix Frank wrote: > On 02/02/2012 02:58 PM, Lars Ellenberg wrote: > >> Technically, if you'd manipulate the local metadata to make your UUID > >> > 36357CED276F2436, DRBD would assume that it can perform a quicksync (I > >> > believe). > ... > > Now the bits are all set, there is no way to "unset" them again. > > Ah, I see now. Manipulating UUIDs could be done with "set-gi", whereas > there is no counterpart for obliterating the bitmap. Of course there is, which is also part of the process of truck based replication (the clear-bitmap part, before you start cloning locally). > I had been thinking of doing something gory with dump-md + restore-md, > anyway (not that I'd heartily recommend trying this kind of thing). Out > of curiosity, though: Is that technically feasible? Sure. The tricky part is, now that most (all?) bits are set, how do you decide which bits you can clear safely, and which must remain set, without first comparing the coresponding data blocks? Right. So why not let DRBD do that comparison for you? -> checksum based resync. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com