<div dir="ltr"><div><div><div>Hi,<br><br></div>I quite new on GlusterFS<br><br></div>Since the arbiter does not hold any data, how to choose it&#39;s size compared to the other 2 bricks?<br><br></div>Regards<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-09 7:26 GMT+01:00 Ravishankar N <span dir="ltr">&lt;<a href="mailto:ravishankar@redhat.com" target="_blank">ravishankar@redhat.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 09/09/2015 08:36 AM, Nagaprasad Sathyanarayana wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks Ravi for nicely explaining this. A question on the following section;<br>
<br>
&quot;If 2 bricks are up and if one of them is the arbiter (i.e. the 3rd brick) and it blames the other up brick, then all FOPS will fail with ENOTCONN (Transport endpoint is not connected). If the arbiter doesn&#39;t blame the other brick, FOPS will be allowed to proceed. &#39;Blaming&#39; here is w.r.t the values of AFR changelog extended attributes.&quot;<br>
<br>
Q: under what circumstances arbiter brick does/does not blame the other brick?<br>
</blockquote>
<br></span>
Blaming is just the term used to indicate the state of AFR changelog xattrs. If a brick is down and a write/ modification FOP happens, then the bricks that are up &#39;blame&#39; the one that is down using the these xattrs.<br>
<br>
Thanks,<br>
Ravi<div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks<br>
Naga<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09-Sep-2015, at 7:17 am, Ravishankar N &lt;<a href="mailto:ravishankar@redhat.com" target="_blank">ravishankar@redhat.com</a>&gt; wrote:<br>
<br>
If 2 bricks are up and if one of them is the arbiter (i.e. the 3rd brick) and it blames the other up brick, then all FOPS will fail with ENOTCONN (Transport endpoint is not connected). If the arbiter doesn&#39;t blame the other brick, FOPS will be allowed to proceed. &#39;Blaming&#39; here is w.r.t the values of AFR changelog extended attributes.<br>
</blockquote></blockquote>
<br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-users</a><br>
</div></div></blockquote></div><br></div>