Description of problem: some of the files not accessible on slave after the geo-rep sync from master to slave, even though the entry for the file is there. For some files which are not accessible from slave don't have extended attributes set in the backend on both replica pairs. Mostly related to Bug 1102550 , Since the behaviour and scenarios are different, filing another bug. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [root@redwood ~]# getfattr -d -m . -ehex /bricks/brick3/slave1_b11/thread0/level07/level17/level27/level37/level47/level57/level67/level77/538728d1%%92861DJTDC getfattr: Removing leading '/' from absolute path names # file: bricks/brick3/slave1_b11/thread0/level07/level17/level27/level37/level47/level57/level67/level77/538728d1%%92861DJTDC trusted.gfid=0x00000000000000000000000000000000 [root@redlemon ~]# getfattr -d -m . -e hex /bricks/brick3/slave1_b12/thread0/level07/level17/level27/level37/level47/level57/level67/level77/538728d1%%92861DJTDC getfattr: Removing leading '/' from absolute path names # file: bricks/brick3/slave1_b12/thread0/level07/level17/level27/level37/level47/level57/level67/level77/538728d1%%92861DJTDC trusted.gfid=0x00000000000000000000000000000000 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Version-Release number of selected component (if applicable): glusterfs-3.6.0.9-1.el6rhs How reproducible: happens most of the time. Steps to Reproduce: 1. create and start a geo-rep relationship between master and slave 2. first create just 1K file using the command, crefi -T 1 -n 10 --multi -b 10 -d 10 --random --min=1K --max=10K /mnt/master1/ 3. after above files gets synced, create files using the command "crefi -T 1 -n 100 --multi -b 10 -d 10 --random --min=1K --max=10K /mnt/master1/" Actual results: Some of the files synced to slave are not accessible Expected results: They should accessible from slave too. Additional info:
In some cases, the files which are not accessible have different gfids on the replica pairs, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> # getfattr -d -m ".*" -e hex /bricks/brick1/slave_b1/thread0/level09/53882fbc%%TJ35N5NY3X getfattr: Removing leading '/' from absolute path names # file: bricks/brick1/slave_b1/thread0/level09/53882fbc%%TJ35N5NY3X trusted.gfid=0x0000000000000000444ca30000000000 # getfattr -d -e hex -m ".*" /bricks/brick1/slave_b2/thread0/level09/53882fbc%%TJ35N5NY3X getfattr: Removing leading '/' from absolute path names # file: bricks/brick1/slave_b2/thread0/level09/53882fbc%%TJ35N5NY3X trusted.gfid=0x00000000000000000000000000000000 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Downstream patch: https://code.engineering.redhat.com/gerrit/#/c/26505/
verified on the build glusterfs-3.6.0.15-1
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1278.html