[Drbd-dev] Problems with code to disallow connection when peer has mismatched UUID

Graham, Simon Simon.Graham at stratus.com
Tue Sep 16 21:14:52 CEST 2008


Hah! I just realized that the current HEAD in the 8.2 tree already
includes this - thanks Phil!

So - just ignore this one.
Simon

> -----Original Message-----
> From: Graham, Simon
> Sent: Monday, September 15, 2008 10:41 AM
> To: Graham, Simon; drbd-dev at linbit.com
> Subject: RE: [Drbd-dev] Problems with code to disallow connection when
> peer has mismatched UUID
> 
> Attached is a proposed patch to address this problem that does the
> following:
> 
> 1. When connection is lost, a new UUID is not created on the primary
if
> the local disk is inconsistent
> 2. Allow connection to be established if local disk is inconsistent
> even if the remote is using
>    a different UUID - our data is useless and cannot have been changed
> anyway. The following handshake
>    will cause the appropriate resync.
> 
> Although only one of these is actually required to fix my problem, I
> thought it was better to be consistent
> and change both.
> 
> Simon
> 
> > -----Original Message-----
> > From: drbd-dev-bounces at linbit.com [mailto:drbd-dev-
> bounces at linbit.com]
> > On Behalf Of Graham, Simon
> > Sent: Thursday, September 11, 2008 6:33 AM
> > To: drbd-dev at linbit.com
> > Subject: RE: [Drbd-dev] Problems with code to disallow connection
> when
> > peerhasmismatched UUID
> >
> > Thanks Lars,
> >
> > > > I'm not sure what the right answer is here, but I have a couple
> of
> > > > observations:
> > > > 1. When we lose connection and are Primary/Inconsistent, should
> we
> > > > really create a new current UUID? The local data is bad.
> > >
> > > I don't think we should.
> >
> > OK - I'll look at implementing this.
> >
> > > that piece of code is to avoid "time warps" of content.
> > > the specific scenario this should protect against is:
> > >
> > > Primary, Connected
> > >  connection breaks.
> > > Primary  ---?
> > >  primary generates new "current uuid",
> > >  and continues to write
> > >  local disk breaks
> > > Primary, Diskless, ---?
> > >  connection heals
> > >
> > > now, if we allow this connection and accept the data of the
> > secondary,
> > > we just jumped back in time.
> >
> > Ah OK -- would it perhaps then be OK to check for local disk state
<=
> > Negotiating instead of < Outdated:
> >
> > 	if (mdev->state.conn < Connected &&
> > 	    mdev->state.disk <= Negotiating &&
> > 	    mdev->state.role == Primary &&
> > 	    (mdev->ed_uuid & ~((u64)1)) != (p_uuid[Current] &
> > ~((u64)1))) {
> > 		ERR("Can only connect to data with current
> > UUID=%016llX\n",
> > 		    (unsigned long long)mdev->ed_uuid);
> > 		drbd_force_state(mdev,NS(conn,Disconnecting));
> > 		return FALSE;
> > 	}
> >
> > This would handle the case we see where we KNOW the local disk does
> not
> > have good data... (and we knew before the connection was lost, so we
> > would NOT have actually been able to change the local copy of the
> data
> > on disk).
> >
> > Simon
> > _______________________________________________
> > drbd-dev mailing list
> > drbd-dev at lists.linbit.com
> > http://lists.linbit.com/mailman/listinfo/drbd-dev


More information about the drbd-dev mailing list