<br><div><span class="q"><span class="gmail_quote">On 11/16/06, <b class="gmail_sendername">Graham, Simon</b> <<a href="mailto:Simon.Graham@stratus.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
Simon.Graham@stratus.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Not sure I agree that the current behavior is protecting users from themselves -- it only causes the split-brain if you lose the n/w and during 'normal' operation and there is nothing that protects against mounting a 1-node fs on both nodes of a primary-primary DRBD cluster.
<br><br>Running primary-secondary doesn't work if you are in a situation where it is not possible to switch primaryness when failing over; a good example of that is if you want to run a Xen virtual machine on top of a DRBD partition and support live migration of the VM (the problem is that Xen doesn't provide the means to execute a script to change primaryness at the required point in the migration). Of course you could argue that this is a Xen bug _but_ pragmatically, the proposed patch to delay updating the UUID until an actual write occurs preserves (I believe) correctness in DRBD and works without introducing new features into Xen.
<br><br>Recovering from split-brain automatically is of course something that is incredibly valuable but I think it can be treated orthogonally to the proposed fix.</blockquote></span><div><br>I think from a technical perspective, automatically recovering from split-brain is nice to have. But from a user perspective, I would in almost all cases refrain from using that feature as I would like to make double sure my data is consistent and makes 'business sense' before electing which disk to be primary.
<br> </div><span class="q">-----Original Message-----<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">From: Philipp Reisner [mailto:<a href="mailto:philipp.reisner@linbit.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
philipp.reisner@linbit.com</a>]<br>Sent: Thursday, November 16, 2006 4:10 AM<br>To: <a href="mailto:drbd-dev@linbit.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">drbd-dev@linbit.com</a><br>Cc: Montrose, Ernest; Graham, Simon
<br>Subject: Re: [Drbd-dev] DRBD8: Split-brain false positive on Primary/primary potential patch
<br><br>Am Dienstag, 7. November 2006 00:47 schrieb Montrose, Ernest:<br>> When running Primary/Primary if the Heartbeat connection goes down when<br>> we recover we always split brain. Simon had an idea which I have
<br>> implemented. He is on vacation so this may not reflect his exact idea.<br>><br>> Essentially with this change, we do not create a new current UUID on the<br>> node unless I/O is seen. This prevent Split-Brain mitigation when both
<br>> nodes are primary but only one node is originating I/O and never the<br>> other. He is only stand-by in that case.<br>><br>> Take a look and let me know.<br><br></blockquote></span></div><br>[snip]