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 8:52 AM, Marcus Sorensen <shadowsor at gmail.com> wrote: > 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. Ah, for clarification, in protocol B we're not talking about the write being 'in buffer' waiting to be flushed to disk, but in drbd memory, correct?