Bug 1000462

https://code.engineering.redhat.com/gerrit/#/c/12602/

Fixed in version please.

closing this as it was part of the errata and cloning this for U1.

*** Bug 1018228 has been marked as a duplicate of this bug. ***

Tried it on the build glusterfs-3.4.0.44rhs. It still fails to sync few symlinks to slave

Steps,

1.create and start geo-rep relationship between master and slave. 
2.create some files on the master and let it sync to slave. 
3.start creating symlinks to created file and parallely disable the changelog. 
4.The geo-rep change_detector falls back to xsync and wait for it to sync files to slave

With the new implementation of xsync crawl and bug fixes in it, this needs to be retested. Please run the relevant test case and verify.

Please provide correct fixed in version. Considering the issue was reproduced in glusterfs-3.4.0.44rhs also , it can't be fixed in glusterfs-3.4.0.33rhs.

Tried on the build glusterfs-3.4.0.52rhs,  It still fails to sync few symlinks to slave

Steps,

1.create and start geo-rep relationship between master and slave. 
2.create some files on the master and let it sync to slave. 
3.start creating symlinks to created file and parallely disable the changelog. 
4.The geo-rep change_detector falls back to xsync and wait for it to sync files to slave

But later enabling the changelog and changing change-detector to changelog would sync the rest of the files. Not sure if this bug should be considered.

Vijay,

As far I know, we always use changelog as the change detector by default
and use xsync to crawl initially if there is existing data and do not 
recommend switching off changelog.

If above is true, I don't see a problem in this.
Correct me if am wrong.

-Kotresh H R

Kotresh, 

Disabling changelog is to simulate the changelog crash. The whole point of introducing xsync was to have a backup if changelog crashes for some reason.

(In reply to Vijaykumar Koppad from comment #13)
> But later enabling the changelog and changing change-detector to changelog
> would sync the rest of the files. Not sure if this bug should be considered.

Are you sure the entry got synced in changelog mode? When the hybrid crawl is used as the main crawling mechanism (i.e. change_detector is 'xsync'), a FS crawl is done every 60 seconds.

(In reply to Vijaykumar Koppad from comment #13)
> But later enabling the changelog and changing change-detector to changelog
> would sync the rest of the files. Not sure if this bug should be considered.

I'm sure the entries (symlinks) did not get synced in changelog mode. When change-logging was disabled, there would be _no_ journal that would capture the symlink creation fop. Enabling change-logging would start journaling for fops thereafter.

(In reply to Vijaykumar Koppad from comment #15)
> Kotresh, 
> 
> Disabling changelog is to simulate the changelog crash. The whole point of
> introducing xsync was to have a backup if changelog crashes for some reason.

That's incorrect. Being a sync backup mechanism is not the sole job for xsync, it's always needed for the first crawl.

Vijay,

I tried with 10k files. It is synching properly with latest
rhs-2.1 downstream. For how many files did you hit this issue?

-Kotresh H R

Vijaykumar,

Could you check comment #17?

I just tried with 52rhs with Venky. The issue is not being reproduced.

Since the change_detector was xsync, syncing takes place for every 60 secs. So one has to wait for 60 secs before seeing the effect.

I will try once more, since vkoppad hit this in 52rhs itself. Will change the status after trying once more. But for now issue is not being reproduced.

I tried once more and all the files including symlinks get synced to slave. But after the sync metadata checksum on regular files in master and slave differs.

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

arequal-checksums on master and slaves after the sync.



[root@gauss ~]# /opt/qa/tools/arequal-checksum /mnt/master/

Entry counts
Regular files   : 44002
Directories     : 2837
Symbolic links  : 44005
Other           : 0
Total           : 90844

Metadata checksums
Regular files   : 3e9
Directories     : 24d74c
Symbolic links  : 5a815a
Other           : 3e9

Checksums
Regular files   : 2f948f83699a8d85afd4b03190c381e6
Directories     : 3b1f6d3f7e6c3b4e
Symbolic links  : 2663f7e20564158
Other           : 0
Total           : b9396df3a7637675


[root@gauss ~]# /opt/qa/tools/arequal-checksum /mnt/slave/

Entry counts
Regular files   : 44002
Directories     : 2837
Symbolic links  : 44005
Other           : 0
Total           : 90844

Metadata checksums
Regular files   : 20f5
Directories     : 24d74c
Symbolic links  : 5a815a
Other           : 3e9

Checksums
Regular files   : 2f948f83699a8d85afd4b03190c381e6
Directories     : 3b1f6d3f7e6c3b4e
Symbolic links  : 2663f7e20564158
Other           : 0
Total           : b9396df3a7637675


There is a different bug for metadata checksum difference between master and slave after sync. Should I verify this bug or should be closed only after that bug is fixed?

MS,

This looks OK. The metadata checksum mismatch is another bug that you've already reported.

We can move this to verified.

Moving this bug to verified. Metadata checksum mismatch will be dealt in different bug.

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