Bug 1001089 - Dist-geo-rep: After running geo-replication upgrade scripts gfids of symlinks and few directories are still different in master and slave
Summary: Dist-geo-rep: After running geo-replication upgrade scripts gfids of symlinks...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: geo-replication
Version: 2.1
Hardware: x86_64
OS: Linux
urgent
high
Target Milestone: ---
: ---
Assignee: Amar Tumballi
QA Contact: M S Vishwanath Bhat
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-26 13:13 UTC by M S Vishwanath Bhat
Modified: 2016-06-01 01:56 UTC (History)
6 users (show)

Fixed In Version: glusterfs-3.4.0.31rhs-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-23 22:38:52 UTC
Embargoed:


Attachments (Terms of Use)

Description M S Vishwanath Bhat 2013-08-26 13:13:13 UTC
Description of problem:
While I was trying the geo-rep upgrade scenario from old-geo-rep to new distributed-geo-rep, I ran geo-rep slave-upgrade script. But I even after running that three times, the symlinks on slave side have different gfid than their master symlinks.

Version-Release number of selected component (if applicable):
glusterfs-3.4.0.20rhs-2.el6rhs.x86_64

How reproducible:
Have tried twice. Out of which I hit only when there was lot of symlinks involved.

Steps to Reproduce:
All these below steps are after the volume upgrade.
1. cd /usr/share/glusterfs/scripts/
2. bash generate-gfid-file.sh localhost:master /usr/share/glusterfs/scripts/get-gfid.sh /tmp/upgrade-gfid-values.txt
3. scp that /tmp/upgrade-gfid-values to one of the slave node.
4. bash slave-upgrade.sh 10.70.35.183:slave ~/upgrade-gfid-values.txt /usr/share/glusterfs/scripts/gsync-sync-gfid 
5. Check the gfid of the master and the slave after this using compare-gfid.py

Actual results:
The symlinks have differing gfids in master and slave. After running it for the first time, the gfid was different for few directories also.


Expected results:
The gfid of all the files in slave should be same as master.

Additional info:

Comment 2 M S Vishwanath Bhat 2013-08-26 13:24:44 UTC
[root@upgrade-2 ~]# getfattr -d -m . -e hex -n glusterfs.gfid /mnt/master/etc.1/pki/tls/cert.pem
getfattr: Removing leading '/' from absolute path names
# file: mnt/master/etc.1/pki/tls/cert.pem
glusterfs.gfid=0x90f0f77db1544233936168959ceb88af

[root@upgrade-2 ~]# getfattr -d -m . -e hex -n glusterfs.gfid /mnt/slave/etc.1/pki/tls/cert.pem
getfattr: Removing leading '/' from absolute path names
# file: mnt/slave/etc.1/pki/tls/cert.pem
glusterfs.gfid=0x90f0f77db1544233936168959ceb88af

[root@upgrade-2 ~]# getfattr -d -m . -e hex -n glusterfs.gfid -h /mnt/slave/etc.1/pki/tls/cert.pem
getfattr: Removing leading '/' from absolute path names
# file: mnt/slave/etc.1/pki/tls/cert.pem
glusterfs.gfid=0x2b4dc2c19051469889e1b5850b695354

[root@upgrade-2 ~]# getfattr -d -m . -e hex -n glusterfs.gfid -h /mnt/master/etc.1/pki/tls/cert.pem
getfattr: Removing leading '/' from absolute path names
# file: mnt/master/etc.1/pki/tls/cert.pem
glusterfs.gfid=0x41e7d3381f0a4b93b6a0c2ca9b4ba600


The targets of the symlinks have same gfids in master and slave but the symlinks themselves have different gfids.

Comment 3 M S Vishwanath Bhat 2013-08-29 12:32:12 UTC
Even few directories had few different gfid's after running the slave-upgrdade.sh for the first time. But after running the same script 3-4 times, they disappeared.

Will try once again with latest build by upgrading from Anshi rpms to latest rpms. (not ISO upgrade)

Comment 4 M S Vishwanath Bhat 2013-09-03 12:31:03 UTC
I did try twice by upgrading from anshi u5 to 30rhs build. But I didn't see this gfid difference for directories. All of those files for which there is difference in gfid is symlinks.

Comment 6 M S Vishwanath Bhat 2013-09-07 15:25:18 UTC
I ran the exact same steps in comment #1. It's working fine now.

Even symlinks will have the same gfid after upgrade now.

Tested in version: glusterfs-3.4.0.32rhs-1.el6rhs.x86_64

Comment 7 Scott Haines 2013-09-23 22:38:52 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/RHBA-2013-1262.html

Comment 8 Scott Haines 2013-09-23 22:41:31 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/RHBA-2013-1262.html


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