Gluster users - Sep 2015 - [Gluster-devel] AFR arbiter volumes

On 09/09/2015 08:36 AM, Nagaprasad Sathyanarayana wrote:
> Thanks Ravi for nicely explaining this. A question on the following
section;
>
> "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't blame the
other brick, FOPS will be allowed to proceed. 'Blaming' here is w.r.t
the values of AFR changelog extended attributes."
>
> Q: under what circumstances arbiter brick does/does not blame the other
brick?
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 'blame' the one that is down using the these
xattrs.

Thanks,
Ravi
>
> Thanks
> Naga
>
>> On 09-Sep-2015, at 7:17 am, Ravishankar N <ravishankar at
redhat.com> wrote:
>>
>> 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't blame the
other brick, FOPS will be allowed to proceed. 'Blaming' here is w.r.t
the values of AFR changelog extended attributes.

Hi,

I quite new on GlusterFS

Since the arbiter does not hold any data, how to choose it's size compared
to the other 2 bricks?

Regards

2015-09-09 7:26 GMT+01:00 Ravishankar N <ravishankar at redhat.com>:
>
>
> On 09/09/2015 08:36 AM, Nagaprasad Sathyanarayana wrote:
>
>> Thanks Ravi for nicely explaining this. A question on the following
>> section;
>>
>> "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't
>> blame the other brick, FOPS will be allowed to proceed.
'Blaming' here is
>> w.r.t the values of AFR changelog extended attributes."
>>
>> Q: under what circumstances arbiter brick does/does not blame the other
>> brick?
>>
>
> 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 'blame' the one that is down using the these
xattrs.
>
> Thanks,
> Ravi
>
>
>> Thanks
>> Naga
>>
>> On 09-Sep-2015, at 7:17 am, Ravishankar N <ravishankar at
redhat.com> wrote:
>>>
>>> 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't
>>> blame the other brick, FOPS will be allowed to proceed.
'Blaming' here is
>>> w.r.t the values of AFR changelog extended attributes.
>>>
>>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20150909/e393b4b9/attachment.html>