<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 23, 2016 at 7:54 PM, Davide Ferrari <span dir="ltr">&lt;<a href="mailto:davide@billymob.com" target="_blank">davide@billymob.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Reading the glusterfs docs<br><br><a href="https://gluster.readthedocs.io/en/latest/Administrator%20Guide/arbiter-volumes-and-quorum/" target="_blank">https://gluster.readthedocs.<wbr>io/en/latest/Administrator%<wbr>20Guide/arbiter-volumes-and-<wbr>quorum/</a><br><br>&quot;In a replica 3 volume, client-quorum is enabled by default and set to &#39;auto&#39;.
This means 2 bricks need to be up for the writes to succeed. Here is how this
configuration prevents files from ending up in split-brain:&quot;<br><br></div>So this means that if one of the machines with the 2 bricks (arbiter &amp; normal) fails, the otherbrick will be set RO, or am I missing something?<br></div>I mean, this config will be better in case of a network loss, and thus a split brain, but it&#39;s far worse in case of a machine failing or being rebooted for maintenance.<br></div></blockquote><div><br></div><div>See the updated vol create command - you should set it up such that 2 bricks in a sub-volume are not from the same host, thus you avoid the problem you describe above<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-09-23 16:11 GMT+02:00 Davide Ferrari <span dir="ltr">&lt;<a href="mailto:davide@billymob.com" target="_blank">davide@billymob.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>2016-09-23 15:57 GMT+02:00 Sahina Bose <span dir="ltr">&lt;<a href="mailto:sabose@redhat.com" target="_blank">sabose@redhat.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div dir="ltr"><span></span><div>You could do this - where Node3 &amp; Node 2 also has arbiter bricks. Arbiter bricks only store metadata and requires very low storage capacity compared to the data bricks.<br></div><div><br></div><div>Node1  Node2     Node3        Node4 <br></div><div>brick1   brick1      arb-brick<br></div><div>            arb-brick  brick1        brick1<br></div></div></blockquote><div><br></div></span><div>Ok, cool! And this won&#39;t pose any problem if Node2 or Node4 fail?<br><br></div><div>The syntax shuld be this:<br><br></div><div>gluster volume create data replica 3 arbiter 1 node1:/brick node2:/brick node2:/arb_brick node3:/brick node4:/brick node4:/arb_brick<br><br></div><div>is not a problem having more than a brick on the same host for the volume create syntax?<br><br></div><div>Thanks again<br><br></div></div><span>-- <br><div><div dir="ltr"><div>Davide Ferrari<br></div>Senior Systems Engineer<br></div></div>
</span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div>Davide Ferrari<br></div>Senior Systems Engineer<br></div></div>
</div>
</div></div></blockquote></div><br></div></div>