[Gluster-devel] Question on choosing source of replica to heal with AFR

[Zhang Huan]

Hello Ravi,

Thanks for your reply.

Sorry that I have a typo in my mail. It should by "underlying corruption"
instead of "underlying correction".

I guess the logic of eliminating zero byte files from all innocent nodes is
working for preventing underlying corruption to propagate to other brick.
Asked in another way, if the underlying brick finds some file is corrupted,
anything it could do to tell glusterfs to fix it?

Zhang Huan


On Thu, Feb 27, 2014 at 7:50 PM, Ravishankar N <ravishankar at redhat.com>wrote:

>  On 02/26/2014 07:42 PM, Zhang Huan wrote:
>
>  Hello guys,
>
>  Anyone know about my question?
>
> Zhang Huan
>
>
> On Sun, Feb 23, 2014 at 11:28 AM, Zhang Huan <zhhuan at gmail.com> wrote:
>
>>  Hello all,
>>
>>  While reading codes about how to choose healing source, there is one
>> thing that confuse me. Say we have 3 replica, and 2 of them are OK and the
>> left one is outdated due to temporary IO failure. For some reason, one of
>> the 2 correct replica is truncated to 0 due to some underlying correction.
>> Will glusterfs kick the 0 size file out? or still consider it a correct one
>> and may corrupt the left correct replica by healing?
>>
>>    Out of the two correct replicas, gluster will pick the first healthy
> replica brick as source [see afr_sh_select_source()]. If that brick is
> truncated at the back-end due to 'underlying correction' (not sure what
> that means), then yes I'm afraid it will still be considered as correct
> source and you would get zero byte file in other 2 bricks because of the
> healing.
>
>    In function afr_mark_sources(), it kicks 0 size file out when all
>> nodes are innocent. Even when all nodes are fools, the file with largest
>> size will be chosen as source. When it comes to the case that there is wise
>> nodes, it won't further check file size. Considering different file size of
>> replicate will trigger healing to work, I am wondering if there is any
>> reason behind the code?
>>
>   The changelog extended attributes are marked  by AFR based on the
> result of whether the file operation succeeded or not on each of the
> replica. It uses those attributes to determine the source/sink. Direct
> modification of the file at the brick will invalidate any meaning that the
> changelog holds.
> Thanks,
> Ravi
>
>
>>  Thanks.
>>
>>  Zhang Huan
>>
>
>
>
> _______________________________________________
> Gluster-devel mailing listGluster-devel at nongnu.orghttps://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140228/1d97412a/attachment-0001.html>