[Bugs] [Bug 1486120] New: symlinks trigger faulty geo-replication state ( rsnapshot usecase)
bugzilla at redhat.com
bugzilla at redhat.com
Tue Aug 29 05:38:57 UTC 2017
https://bugzilla.redhat.com/show_bug.cgi?id=1486120
Bug ID: 1486120
Summary: symlinks trigger faulty geo-replication state
(rsnapshot usecase)
Product: GlusterFS
Version: 3.12
Component: geo-replication
Keywords: Triaged
Severity: high
Assignee: bugs at gluster.org
Reporter: khiremat at redhat.com
CC: avishwan at redhat.com, bugs at gluster.org,
khiremat at redhat.com, lohmaier+rhbz at gmail.com,
ndevos at redhat.com
Depends On: 1432046
Blocks: 1431081
+++ 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.
--- Additional comment from Worker Ant on 2017-08-09 06:36:51 EDT ---
REVIEW: https://review.gluster.org/18011 (geo-rep: Fix syncing of hardlink of
symlink) posted (#2) for review on master by Kotresh HR (khiremat at redhat.com)
--- Additional comment from Worker Ant on 2017-08-23 23:13:56 EDT ---
COMMIT: https://review.gluster.org/18011 committed in master by Aravinda VK
(avishwan at redhat.com)
------
commit e893962deaabab8e934813f8a0443a8f94e009f2
Author: Kotresh HR <khiremat at redhat.com>
Date: Tue Aug 8 10:12:14 2017 -0400
geo-rep: Fix syncing of hardlink of symlink
Problem:
If there is a hardlink to a symlink on master
and if the symlink file is deleted on master,
geo-rep fails to sync the hardlink.
Typical Usecase:
It's easily hit with rsnapshot use case where
it uses hardlinks.
Example Reproducer:
Setup geo-replication between master and slave
volume and in master mount point, do the following.
1. mkdir /tmp/symlinkbug
2. ln -f -s /does/not/exist /tmp/symlinkbug/a_symlink
3. rsync -a /tmp/symlinkbug ./
4. cp -al symlinkbug symlinkbug.0
5. ln -f -s /does/not/exist2 /tmp/symlinkbug/a_symlink
6. rsync -a /tmp/symlinkbug ./
7. cp -al symlinkbug symlinkbug.1
Cause:
If the source was not present while syncing hardlink,
it was always packing the blob as regular file.
Fix:
If the source was not present while syncing hardlink,
pack the blob based on the mode.
Change-Id: Iaa12d6f99de47b18e0650e7c4eb455f23f8390f2
BUG: 1432046
Signed-off-by: Kotresh HR <khiremat at redhat.com>
Reported-by: Christian Lohmaier <lohmaier+rhbz at gmail.com>
Reviewed-on: https://review.gluster.org/18011
Smoke: Gluster Build System <jenkins at build.gluster.org>
CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
Reviewed-by: Aravinda VK <avishwan at redhat.com>
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1431081
[Bug 1431081] symlinks trigger faulty geo-replication state (rsnapshot
usecase)
https://bugzilla.redhat.com/show_bug.cgi?id=1432046
[Bug 1432046] symlinks trigger faulty geo-replication state (rsnapshot
usecase)
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
More information about the Bugs
mailing list