[Drbd-dev] How Locking in GFS works...

Philipp Reisner philipp.reisner at linbit.com
Fri Oct 8 15:37:23 CEST 2004

Am Freitag, 8. Oktober 2004 14:55 schrieb Lars Marowsky-Bree:
> On 2004-10-08T14:32:09, Philipp Reisner <philipp.reisner at linbit.com> wrote:
> >   3. Concurrent writes, high latency for data packets.
> >     The problem now is that N2 does can not detect that this was
> >     a concurrent write, since it got the ACK before the conflicting
> >     data packets comes in.
> Uhm. I don't see how this can be a problem.
> In this case, one write has logically happened before the other, and
> from they don't overlap - the second write will simply wipe out the
> first one, which seems fine?

Just look at it again. on the left figure you will find that N1 has
the blue data on its block and N2 has the green data on its disk. 

I do see here a problem.

> >   5. New write while processing a write from the peer.
> Sounds just like case 1.

In case 1 there is no concurrenct access at all ?!?

Hav you had a look at the pdf ?


More information about the drbd-dev mailing list