[Drbd-dev] Another drbd race
lars.ellenberg at linbit.com
Wed Sep 8 17:22:42 CEST 2004
On Wed, Sep 08, 2004 at 05:11:30PM +0200, Lars Marowsky-Bree wrote:
> On 2004-09-08T13:31:10,
> Lars Ellenberg <lars.ellenberg at 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
> _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
> But, we are already pretty far in lala land.
> > 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
More information about the drbd-dev