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 10:06:51AM +0100, Felix Frank wrote: > Hi, > > On 02/02/2012 08:45 AM, Richard Baverstock wrote: > > I'm wondering if there's anything we can do to get drbd to recognize the > > data that is currently on the server that is out of date. > > I can imagine there is, but it's going to be ugly and dangerous. > > > ... self 704EEF7DCB91803C:0000000000000000:E16701DDDCBB997C:F572CBCF520DFB48 > > bits:56 flags:0 > > ... peer D7B6E3DCB6C68EBD:36357CED276F2437:E16701DDDCBB997D:F572CBCF520DFB48 > > bits:265245 flags:2 > > Technically, if you'd manipulate the local metadata to make your UUID > 36357CED276F2436, DRBD would assume that it can perform a quicksync (I > believe). > > Again: This is obviously far from clean or safe (and I don't know where > one could find info on how to do it). Now the bits are all set, there is no way to "unset" them again. What you could do is enable "checksum based resync", I'd suggest a strong hash, to trade CPU cycles against bandwidth. You will still need to read all the data on both nodes, but the blocks will not be transfered if the checksums match. > Personally, I'd rather mail a hard disk and do > http://www.drbd.org/users-guide/s-truck-based-replication.html Right. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com