[Bugs] [Bug 1336098] heal info command takes tens of minutes when in split-brain situation.

bugzilla at redhat.com bugzilla at redhat.com
Mon Jun 27 12:19:14 UTC 2016


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

René Pavlík <skyrat at email.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?(skyrat at email.cz)  |



--- Comment #2 from René Pavlík <skyrat at email.cz> ---
Hi, Pranith,

not exactly the steps, but I can give you a description of our setup and the
triggers of that split-brain. The main aspect of this bug report is to have
reliable, always-returning-something tool to detect a split-brain - for example
by an external monitoring system, invoking the command each minute or so. I
have seen the reported behavior every time our setup had a connection issues
and gfid split-brain occurred. But the lasting time of the command depends on
the extent of the damage.

Our setup:
- 3 replicated nodes with client quorum
- 15 servers having the cluster mounted locally, rsyncing their data to the
glusterfs, to their own directories (sharing the same, common parent dir)
- the files are only being appended with new data or new files are being added,
no deletion
- when there is a connection issue, the gfid split-brain occurs: on each brick,
there is the latest data file with different size and gfid, or is missing
entirelly on some bricks.
- the total amount of the files in real split-brain is about 50
- sometimes also the containing directory has this issue

In such situation we would like to detect the split-brain but the issue
reported occurs.

I'm sorry, that I cannot give you exact scenario, where you would directly see
the issue. Hope this helps.

If you need additional info, please ask.

Thanks.

Rene

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


More information about the Bugs mailing list