[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 ?

-Philipp


More information about the drbd-dev mailing list