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, Jul 03, 2014 at 01:52:07AM -0500, Zev Weiss wrote: > Hello, > > I ran into some undesired behavior from DRBD earlier today -- I'm > running 8.4.4 on CentOS 6.5 (kernel 2.6.32-431.17.1.el6.x86_64), with > a fairly vanilla two-node, single-primary config replicating over a > back-to-back 10GbE link. > > The DRBD resource in question holds a backup volume that we rotate a > disk from periodically to take offsite, replacing it with the > previously-offsite disk and then resyncing to that. On the node > (let's call it node0, and the other node1) that I was swapping the > drive into/out of, I ran 'drbdadm detach' on the resource, leaving it > temporarily diskless, and then 'drbdadm attach' with the > newly-swapped-in disk once it was up and ready. Given that the > freshly-attached backing device would be from an older state of the > same resource, I was hoping that DRBD would recognize this and do a > bitmap-based resync of only the data that had been modified since that > drive was most recently rotated out (I later realized this part of it > wasn't likely to work out as I'd hoped). No, it won't. In fact, it "should" refuse the attach in the first place. > Instead what happened when I re-attached was that node1 (the peer, not > the one the detach/attach was done on) reported observing unrelated > data and aborted, while node0 remained stuck in dstate Negotiating, > where it appeared happy to remain indefinitely. If you can, please try to reproduce with current drbd 8.4.5. I have reason to believe this may have been fixed in the state handling meanwhile. If it is still broken, we need to fix it eventually. Meanwhile: don't do that, then :-/ -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed