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