Bug 1002999

Summary: Dist-geo-rep : geo-rep failed to remove files in slave, when those were removed on master through nfs mount as unprivileged user.
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Vijaykumar Koppad <vkoppad>
Component: geo-replicationAssignee: Ajeet Jha <ajha>
Status: CLOSED ERRATA QA Contact: Vijaykumar Koppad <vkoppad>
Severity: high Docs Contact:
Priority: medium    
Version: 2.1CC: aavati, ajha, bbandari, csaba, khiremat, nsathyan, psriniva, rhs-bugs, vagarwal, vraman
Target Milestone: ---Keywords: ZStream
Target Release: RHGS 2.1.2   
Hardware: x86_64   
OS: Linux   
Whiteboard:
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: Environment:
Last Closed: 2014-02-25 07:36:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Vijaykumar Koppad 2013-08-30 12:43:32 UTC
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:

Comment 2 Amar Tumballi 2013-11-26 07:10:51 UTC
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 07:19:58 UTC
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 07:32:27 UTC
Please fill in fixed in version.

Comment 5 Vijaykumar Koppad 2013-12-24 08:29:39 UTC
verified on the build glusterfs-3.4.0.52rhs.

Comment 6 Kotresh HR 2014-01-02 05:05:38 UTC
Added Doc Text.

Comment 7 Pavithra 2014-01-08 07:15:53 UTC
Please review the doc text for technical accuracy.

Comment 8 Ajeet Jha 2014-01-08 07:20:43 UTC
Doc-text looks ok to me.

Comment 9 Kotresh HR 2014-01-08 07:30:50 UTC
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 07:36:28 UTC
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