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 09:11:25AM -0700, Marcus Sorensen wrote: > 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." ^^^ You even quoted the paragraph. Anything unclear about that? > >>> > >>> 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? > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed