[Bugs] [Bug 1503174] New: symlinks trigger faulty geo-replication state ( rsnapshot usecase)

bugzilla at redhat.com bugzilla at redhat.com
Tue Oct 17 13:32:23 UTC 2017


            Bug ID: 1503174
           Summary: symlinks trigger faulty geo-replication state
                    (rsnapshot usecase)
           Product: Red Hat Gluster Storage
           Version: 3.3
         Component: geo-replication
          Keywords: Triaged
          Severity: high
          Assignee: avishwan at redhat.com
          Reporter: khiremat at redhat.com
        QA Contact: rhinduja at redhat.com
                CC: avishwan at redhat.com, bugs at gluster.org,
                    csaba at redhat.com, khiremat at redhat.com,
                    lohmaier+rhbz at gmail.com, ndevos at redhat.com,
                    rhs-bugs at redhat.com, storage-qa-internal at redhat.com
        Depends On: 1432046
            Blocks: 1431081, 1486120

+++ 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:

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.

Referenced Bugs:

[Bug 1431081] symlinks trigger faulty geo-replication state (rsnapshot
[Bug 1432046] symlinks trigger faulty geo-replication state (rsnapshot
[Bug 1486120] symlinks trigger faulty geo-replication state (rsnapshot
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=wcC4b5CAAY&a=cc_unsubscribe

More information about the Bugs mailing list