Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wed, Jun 22, 2011 at 09:41:27AM +0200, Felix Frank wrote: > Hi, > > On 06/22/2011 08:29 AM, Gianluca Cecchi wrote: > > Certainly it is not my intention to bypass DRBD. In fact in my e-mail > > yet that is what you inadvertantly did. DRBD has no possible way of > finding out that you messed with its backing storage. Well, except you > do an online verify, which is expensive. > > > I tried to clarify that it was a simulation of changed data before > > resync. > > This can happen if the "remote" side becomes Primary while disconnected. > The result is a split-brain, which must be resolved one way or another > (usually by human intervention - you get to decide whose changes should > get trashed). See > http://www.drbd.org/users-guide/s-resolve-split-brain.html. > > Again: If someone decides to mess with DRBD *backing storage*, chances > are it will never be detected unless you run verify. > > > b) > > drbdadm invalidate-remote r0 > > Sure, fencing your peer is a way of safe-guarding yourself against > split-brain. Though the statement in itself is correct, "invalidate-remote" has NOTHING to do with fencing. -- : 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