Bug 1002999 - Dist-geo-rep : geo-rep failed to remove files in slave, when those were removed on master through nfs mount as unprivileged user.
Dist-geo-rep : geo-rep failed to remove files in slave, when those were remov...
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: geo-replication (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: RHGS 2.1.2
Assigned To: Ajeet Jha
Vijaykumar Koppad
: ZStream
Depends On:
  Show dependency treegraph
Reported: 2013-08-30 08:43 EDT by Vijaykumar Koppad
Modified: 2015-05-13 12:34 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, metadata was not being synced to the slave volume and this led to a Geo-replication failure when the owner is changed and removed on the master volume by a new owner. With this update, the metadata changes related to chmod()and chown()are processed and synced.As a result, Geo-replication process can successfully remove files on the slave volume through a new owner.
Story Points: ---
Clone Of:
Last Closed: 2014-02-25 02:36:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Vijaykumar Koppad 2013-08-30 08:43:32 EDT
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-

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:
Comment 2 Amar Tumballi 2013-11-26 02:10:51 EST
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.
Comment 3 Ajeet Jha 2013-12-11 02:19:58 EST
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.
Comment 4 Vijaykumar Koppad 2013-12-24 02:32:27 EST
Please fill in fixed in version.
Comment 5 Vijaykumar Koppad 2013-12-24 03:29:39 EST
verified on the build glusterfs-
Comment 6 Kotresh HR 2014-01-02 00:05:38 EST
Added Doc Text.
Comment 7 Pavithra 2014-01-08 02:15:53 EST
Please review the doc text for technical accuracy.
Comment 8 Ajeet Jha 2014-01-08 02:20:43 EST
Doc-text looks ok to me.
Comment 9 Kotresh HR 2014-01-08 02:30:50 EST
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.
Comment 11 errata-xmlrpc 2014-02-25 02:36:28 EST
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.


Note You need to log in before you can comment on or make changes to this bug.