[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