[Gluster-users] Question about trusted.afr

[Karthik Subrahmanya]

Hey Tamal,

Sorry for the delay. See my comments inline.

On Tue, Feb 28, 2017 at 10:29 AM, Tamal Saha <tamal at appscode.com> wrote:

> Hi,
> I am running a GlusterFS cluster in Kubernetes. This has a single 1x2
> volume. I am dealing with a split-brain sitution. During debugging I
> noticed that, the files in the backend bricks does not have the proper
> trusted.afr xattr. Given this volume has 2 bricks, I should see
> files with the  following 2 afr, I am guessing:
>
> trusted.afr.vol-client-0
> trusted.afr.vol-client-1
>
> But I see files with xattrs below:
>
> trusted.afr.vol-client-2
> trusted.afr.vol-client-3
> trusted.afr.vol-client-5
>
> As I run the bricks as pods in Kubernetes, I have from time to time added
> and removed bricks fron this volume. Basically the pod IPs changed when the
> pods get restarted. My questions are:
>
> 1. Am I seeing wrong trusted.afr?
>
AFAIK, the numbers 2,3,and 5 you are seeing in trusted.afr is because you
had added bricks to your volume. This is because of the change [1].
I suspect that you are getting 3 brick IDs in the changelog, since it was
1x3 volume after adding the brick to the volume.
You can check for the brick IDs/name of the trusted.afr attributes in the
vol file "<volname>.tcp-fuse.vol" and grep for "afr-pending-xattr"

> 2. When I remove-brick and add a new brick and then run heal full, does it
> reapply the trusted.afrs properly?
>
What do you mean by reapplying trusted.afr? Are you referring to changing
the values of attributes or changing the brick IDs?

[1]
https://github.com/gluster/glusterfs-specs/blob/master/done/GlusterFS%203.6/Persistent%20AFR%20Changelog%20xattributes.md

>
> Thanks,
> -Tamal
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170301/24b7659b/attachment.html>