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

[Graham, Simon]

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