<div dir="ltr"><div class="gmail_extra">Many thanks for the detailed reply Ravishankar<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 October 2015 at 16:27, Ravishankar N <span dir="ltr"><<a href="mailto:ravishankar@redhat.com" target="_blank">ravishankar@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div>Question:<br>
</div>
<div>- Which is better, server or client quorums?<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></span>
You can still end up in split-brain of the files stored in the
volume if sever quorum is enabled. Sever quorum is more useful to
avoid conflicts in volume configuration since it also disallows
volume set commands, peer probe etc when not in quorum. Client
quorum is better if you want to avoid split-brains of files present
in the volume.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>- Can you safely enable both? recommended?<br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></span>
IMHO, client-quorum is enough. In case of dist-rep volumes, it acts
on only those replica sets where quorum is not met making only that
replica pair EROFS. Server quorum outright kills the bricks, not
even allowing read access. But yes, you can enable both. <br>
</blockquote></div><br><br></div><div class="gmail_extra">I'll think about that, but sounds like just client quorum is sufficient, though with VM hosting you probably don't even want read access.<br><br></div><div class="gmail_extra">One thing, just to clarify - client quorum is controlled by the following settings?<br><br>- cluster.quorum-type<br>- cluster.quorum-count<br><br><br></div><div class="gmail_extra">Thanks and Cheers,<br><br></div><div class="gmail_extra"><br><br clear="all"><br>-- <br><div class="gmail_signature">Lindsay</div>
</div></div>