but in protocol a, the change is saved in network buffer and send to peer. peer may receive x,y,z at the same time and write to local backend device . Because the generic_make_request is async . We should need some mechenism to make sure y is written to backend device just after x is written completely.
2015-12-23 12:52 GMT+08:00 Digimer <[email protected]>: > On 22/12/15 11:11 AM, 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? >> >> Thanks. > > It will always be the same so long as the peer is connected. That is, > Primary writes X, change is sent to peer, write is confirmed complete. > Primary writes Y (repeat). The only thing that changes is is when the > primary considers the write to be complete which depends on your > protocol (c == hits storage on the peer, b == received on the peer's > network, a == hits the local machines network stack). > > -- > Digimer > Papers and Projects: https://alteeve.ca/w/ > What if the cure for cancer is trapped in the mind of a person without > access to education? _______________________________________________ drbd-user mailing list [email protected] http://lists.linbit.com/mailman/listinfo/drbd-user
