[DRBD-user] writer order on secondary site

Lars Ellenberg lars.ellenberg at linbit.com
Thu Dec 24 16:49:06 CET 2015

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

On Wed, Dec 23, 2015 at 12:11:51AM +0800, Mia Lueng wrote:
> Hi:
> I'm just wondering how secondary handle the write ordering when a same
> block is written twice on primary.
> Application submits these updates: X, Y, Z.
> They may or may not be to the same block.
> If they are to the same block, then the application, file system
> or other layer already makes sure (or at least is supposed to do that),
> that the first update will finish before the second is submitted.
> These updates are replicated to the peer.
> When X,Y are to the same block, how secondary site make sure that the
> first update will finish before the second is summited?

In synchronous mode, this is trivially obvious.
In asynchronous mode, we have DRBD barriers, and epochs.

Basic idea is: whenever we complete something to upper layers,
we bump an atomic epoch counter.
Anything sumitted within one epoch cannot possibly depend on
something else within that same epoch.
So within such an epoch, reordering is allowed.
"on the wire", epochs are separated by "DRBD barriers".
Receiving side uses drain/flush/barrier (depending on configuration)
to make sure anything from a previous epoch is on stable storage
before starting to submit for the next epoch.

: Lars Ellenberg
: http://www.LINBIT.com | Your Way to High Availability
: DRBD, Linux-HA  and  Pacemaker support and consulting

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
please don't Cc me, but send to list   --   I'm subscribed

More information about the drbd-user mailing list