[Bugs] [Bug 1262964] Cannot access volume when network down

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1262964



--- Comment #20 from Huy VU <huy.vu at mitel.com> ---
(In reply to Atin Mukherjee from comment #18)
> (In reply to Huy VU from comment #15)
> > (In reply to Ravishankar N from comment #14)
> > > Hi VU,
> > > 
> > > Writing to the same file from the clients on both nodes where the node can
> > > only see itself and not the other can result in split-brains. Is that not
> > > what you did? If not I may have misunderstood the steps.
> > 
> > Ravi,
> > I am sorry for not making the steps clearer.
> > 
> > I used vi to add a few lines to the file on one node while the NIC card of
> > the other node was forced down. Then I brought the NIC card up. That was
> > enough to cause split brain.
> > 
> > I am also interested in knowing why there was a 30 second hang on both nodes
> > when the NIC card was brought down.
> glusterd's ping time out value is 30 secs. So in case of any node/network
> going faulty the other parties may not get a disconnect notification back as
> tcp keep alive never guarantees that. Its the application's responsibilities
> to have heart beats to detect such failures. In this case after 30 secs the
> time out happened and during that interval you observed the hang which is
> expected.
> Hope this clarifies the point here.
> 
> Ravi,
> 
> since I do not see this behaviour as an issue. moving the component back to
> replicate
> > 
> > NOTE: I tested directly on the two nodes. i.e. the vi command was run
> > directly on node 1. I don't think this should have any bearing on the
> > behaviour.
Atin,

If this behaviour is as intended then so be it; you can close this bug.
However, I would think it's an area of improvement. The current behaviour can
be described as synchronous replication. If there is a control flag for us to
choose asynchronous replication that would improve performance tremendously.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.