Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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 <lists at alteeve.ca>: > 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?