+++ This bug was initially created as a clone of Bug #1432046 +++ +++ This bug was initially created as a clone of Bug #1431081 +++ +++ +++ +++ Use this bug to get a fix in the master branch before +++ +++ backporting it to the maintained versions. +++ Description of problem: operations as done by rsnapshot easily trigger faulty geo-replication state Version-Release number of selected component (if applicable): 3.10, but 3.8 affected the same way How reproducible: 100% Steps to Reproduce: 0) create volume on master and slave and setup geo-replication between them 1) mount master volume and cd to it (nfs or fuse doesn't make a difference) 2) simulate a rsnapshot run that updates a symlink like this: mkdir /tmp/symlinkbug ln -f -s /does/not/exist /tmp/symlinkbug/a_symlink rsync -a /tmp/symlinkbug ./ cp -al symlinkbug symlinkbug.0 ln -f -s /does/not/exist2 /tmp/symlinkbug/a_symlink rsync -a /tmp/symlinkbug ./ cp -al symlinkbug symlinkbug.1 (rsnapshot uses hardlinks between rotations, that's why it is using cp -al) Actual results: geo-replication goes to faulty state, and symlinkbug/a_symlink still points to the old location Expected results: geo-replication should update the link destination, and not choke/go into faulty state on the second cp -al Additional info: you can pause in between the steps, add checkpoints and verify those to have all steps synced separately - doesn't make a difference.
Upstream Patch is already merged and comes to downstream 3.4 as part of rebase. https://review.gluster.org/18011
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. https://access.redhat.com/errata/RHSA-2018:2607