[DRBD-user] protocol B in dual-primary mode

Marcus Sorensen shadowsor at gmail.com
Tue Dec 13 16:52:27 CET 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On Tue, Dec 13, 2011 at 4:40 AM, Lars Ellenberg
<lars.ellenberg at linbit.com> wrote:
> On Mon, Dec 12, 2011 at 09:35:01PM -0700, Marcus Sorensen wrote:
>> "in dual primary mode, only protocol C is allowed.
>>
>> cluster file system deals with cache coherence,
>> DRBD has to deal with storage coherence.
>> you cannot do that asynchronously.
>>
>> to do that in protocol B, the receiving node would need to be able to
>> access data of in-flight requests, which is not implemented."
>>
>> But what if you're not using a filesystem?
>
> Ok, so you are using "whatever", and you think you want dual-primary DRBD,
> but you want it to replicate asynchronously despite of that.
>
> What if "whatever" writes something to node A,
> node A completes the write,
> and "whatever" has all right to assume this actually hit stable storage.
>
> Then (the same or a different instance of) "whatever" wants to read that
> change from node B, but the change is not yet on B, because it
> replicated async.
>
> "whatever" would be slightly surprised,
> and you would start screaming drbd ate my data.
>
> Well, no, it did not. You screwed up.
> And this particular screwup DRBD does not allow.

So you're saying that protocol B, in active-active, would not read
from memory on the second node. So even if we wait until a write to
block 213456 has replicated to memory on node B, if a read comes in
for block 213456 on node B, it's going to go to disk for the read, and
ignore the outstanding write until it's on disk. This is good to know,
and not what I would have expected.



More information about the drbd-user mailing list