Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
I found the checksum based sync last night after sending the email - thanks for pointing it out though. I'm doing the sync now. Is there any way to see what drbd is able to match via the checksums? Thanks, Richard On Thu, Feb 2, 2012 at 6:19 AM, Lars Ellenberg <lars.ellenberg at linbit.com>wrote: > 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 > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20120202/64cfc7fc/attachment.htm>