Description of problem: geo-rep failed remove files in slave, when those were removed through nfs mount as non-root user. The files which were removed through nfs mount as unprivileged user, were removed properly from master. Those unlinks got entries in changelog also, and they were moved to .processing directory. [root@redmoon cfdffea3581f40685f18a34384edc263]# ls .processing/ CHANGELOG.1377856221 CHANGELOG.1377856241 [root@redmoon cfdffea3581f40685f18a34384edc263]# these didn't get processed by geo-rep even after the 3 hours. but the if you grep for the file name in change.log in working dir, you get entries,but it hasn't moved them to .processed directory. and also geo-rep status was stable for whole period and change_detector is changelog. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [root@redmoon cfdffea3581f40685f18a34384edc263]# grep CHANGELOG.1377856241 changes.log [2013-08-30 09:50:41.566902] D [gf-changelog-process.c:501:gf_changelog_ext_change] 0-glusterfs: processing changelog: /bricks/brick3/.glusterfs/changelogs/CHANGELOG.1377856241 [root@redmoon cfdffea3581f40685f18a34384edc263]# grep CHANGELOG.1377856221 changes.log [2013-08-30 09:50:21.546326] D [gf-changelog-process.c:501:gf_changelog_ext_change] 0-glusterfs: processing changelog: /bricks/brick3/.glusterfs/changelogs/CHANGELOG.1377856221 [root@redmoon cfdffea3581f40685f18a34384edc263]# >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The above logs means that, they were processed by the geo-rep , but ignored for some reason Version-Release number of selected component (if applicable):glusterfs-3.4.0.24rhs-1.el6rhs.x86_64 How reproducible: didn't try to reproduce Steps to Reproduce: 1.create and start a geo-rep relationship between master and slave. 2.create data on master through nfs mount as unprivileged user. 3.let the files sync to slave. 4. Then delete the files through same mnt_pnt Actual results: Failed to remove some files from the slave Expected results:It should remove files on slave too , when it is remove on master. Additional info:
Along with most of the fixes which went in for Update1 for geo-replication, this should be fixed (ie, we had not seen this issue), but still keeping it assigned so we do few more round of unit test before handing over to QE.
The bug was not reproducible and has got fixed with the updates that have gone in. Changing status to ON_QA, so that it can be tested with the next build.
Please fill in fixed in version.
verified on the build glusterfs-3.4.0.52rhs.
Added Doc Text.
Please review the doc text for technical accuracy.
Doc-text looks ok to me.
In first paragraph, I think adding the word "files" makes more sense. ...and files are removed on the master volume by a new owner. It is fine other than that.
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-0208.html