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, Nov 02, 2016 at 09:25:58AM +1100, Adam Goryachev wrote: > On 02/11/16 00:44, adream wrote: > >hi guys > > I'm curious about implementation of drbd's protocol c, is there any > >document describe the detail of the protocol c ? > >giving an situation, > >I have two node, node A works as primary, and node B works as secondary, > >the drbd works in protocol c. > >then I write some date in node A, for example i vi create file named > >t.txt, and write "hello drbd" into the node A. > >In the node B, the drbd has just created t.txt and receive "hello" from > >node A, then some terrible thing happened, the the connections between > >node A and node B broken, and node B will never receive the rested > >message. > >so in this situation, if i mount the drbd in the node B, what will i see? > >a t.txt file with "hello " message, or nothing, or something else? > >looking forward to any reply. > >thanks > > > > You mean like in the documentation: > https://www.drbd.org/en/doc/users-guide-84/s-replication-protocols > Or in the source code? > Either way, I think this is pretty well documented, but I'll try and explain > further by example... > In your scenario, if you create a file (touch t.txt) and then write "hello > drbd" into the file (echo "hello drbd" > t.txt) then you have three possible > outcomes. Either Node B will not have the file (if the crash happened before > your touch command returned the success message), or it will have an empty > file if the crash happened after the touch command returned the success > message and before the echo command returned, or it will contain the content > "hello drbd" if the crash was after the echo command completed. > > So, whatever Node A says has been done, will have been done on Node B. In > actual fact, this would be the same for Protocol B as well (assuming by > crash you mean Node A vanished at that instant). Also, remember that DRBD is a BLOCK device. And write() typically goes through the operating system cache first, whatever you wrote may not even have reached the block device layer yet. You want to sync, fsync, or fdatasync. In DRBD protocol C, when fsync() returns, data has been persisted on all nodes. Which means if you have a crash-safe-on-single-node application, it will be crash-safe for DRBD protocol C as well. If you are not even crash safe on a single node setup, DRBD won't magically make it so. -- : Lars Ellenberg : LINBIT | Keeping the Digital World Running : DRBD -- Heartbeat -- Corosync -- Pacemaker DRBD® and LINBIT® are registered trademarks of LINBIT __ please don't Cc me, but send to list -- I'm subscribed