Hey Tamal,
Sorry for the delay. See my comments inline.On Tue, Feb 28, 2017 at 10:29 AM, Tamal Saha <tamal@xxxxxxxxxxxx> 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 seefiles with the following 2 afr, I am guessing:trusted.afr.vol-client-0trusted.afr.vol-client-1But I see files with xattrs below:trusted.afr.vol-client-2trusted.afr.vol-client-3trusted.afr.vol-client-5As 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
[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@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-users
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users