On 02/28/2014 07:28 AM, Zhang Huan wrote:
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?
Hi Zhang,
If all nodes are innocent (from AFR's point of view) ,then AFR cannot
use the changelog attributes to determine which is source. In this case,
the safest bet is to mark all zero byte files as sink, so that we don't
end up healing in the wrong direction. Like I said earlier, AFR can
only use the changelog attributes (xattrs) to determine the
source/sinks. It cannot detect underlying on disk file system
corruptions outside the scope of the xattrs.
If you are sure that a particular brick is the right source despite the
xattrs saying otherwise, you can manually change the attributes of the
file on all bricks so that AFR now sees that brick as the source and
heals in the expected direction.
-Ravi
Zhang Huan
On Thu, Feb 27, 2014 at 7:50 PM, Ravishankar N <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 list
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/gluster-devel
