Re: [Drbd-dev] Another drbd race

[Lars Ellenberg <lars.ellenberg@linbit.com>]

On Wed, Sep 08, 2004 at 05:11:30PM +0200, Lars Marowsky-Bree wrote:
> On 2004-09-08T13:31:10,
>    Lars Ellenberg <lars.ellenberg@linbit.com> said:
> 
> > > So, why an explicit drbdadm fence operation? I'm missing what that would
> > > catch.
> > 
> > we probably can cope without, but it is more "polite" if we have it.
> > if we _can_ handle it explicit, why not?
> 
> We _need_ to handle it implicitly in case we lose the connection in that
> scenario.
> 
> _Explicitly_ setting the outdated flag in some more scenarios may also
> be appropriate, yes.

that is what I said. :)

> 
> > implicit things are more easy to overlook...
> > 
> > and:
> >   P --- S  
> >   P xxx S        link breaks
> > 
> >   [ you can insert here even a complete cluster crash ]
> 
> That's a triple fault already!
> 
> >   X xxx S        N2 receives "Peer dead", but still is outdated.
> 
> That is a quad-fault!!! (Link lost, two nodes down, one node not coming
> up)

...

> But, we are already pretty far in lala land.

right :)

> 
> >   the point is: just receiving a "peer definetely dead" in S/?
> >   is not enough to know that we are not outdated.
> 
> Right. But the fence doesn't help much either, for we need to set that
> flag in that scenario even if the 'fence' event just isn't delivered.

what I want to hav in is just a cover-my-ass thingy to require explicit
confirmation before possibly losing (application-wise) confirmed data
transactions.

	Lars