Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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. > What if you're just > exporting drbd block, active-active devices via say, iscsi or SAS > target? As you will find in the archives of this ML, don't do that, not even with protocol C. > Couldn't the initiator just treat them as the same disk, > multipathed? In which case if one of your two DRBD nodes goes down, > all you care about is that the second node has the writes in memory *in memory where no block device read can get to, yet* > (because if the second goes down at the same time you're hosed > anyway). So feel free to use protocol B, and get your "classic" "promote, start services and IPs" failover right. Note that sometimes B is even slower as C (depends on the actual usage pattern, the IO backend, and a lot of other things probably). -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com