Bug 1476208 - [geo-rep]: few of the self healed hardlinks on master did not sync to slave
Summary: [geo-rep]: few of the self healed hardlinks on master did not sync to slave
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: geo-replication
Version: 3.12
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Kotresh HR
QA Contact:
URL:
Whiteboard:
Depends On: 1474380 1475308 1476212
Blocks: glusterfs-3.12.0
TreeView+ depends on / blocked
 
Reported: 2017-07-28 09:48 UTC by Kotresh HR
Modified: 2017-09-05 17:37 UTC (History)
9 users (show)

Fixed In Version: glusterfs-3.12.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1475308
Environment:
Last Closed: 2017-09-05 17:37:48 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Kotresh HR 2017-07-28 09:48:18 UTC
+++ This bug was initially created as a clone of Bug #1475308 +++

+++ This bug was initially created as a clone of Bug #1474380 +++


Description of problem:
=======================

In the following scenario, the sync of hardlinks do not happen to slave. 

Scenario 1:

1. Create geo-rep between master and slave
2. Mount the volume
3. Create a file (file1)
4. Let the file sync to slave
5. kill one set of replica for a subvolume containing file1
6. create a hardlink of file1 (ln file1 file2).=> Ensure that the file2 hashes to the same subvolume of file1
7. Start the master volume forcefully to heal file2 . Wait for heal to happen
8. Kill the other set of the replica (than the step 5)
9. Start the geo-replication

In the above scenario the hardlinks are not synced to slave and there are no errors. 

Scenario 2:

Step 1 to Step 5 remains same
6. create a hardlink of file1 (ln file1 file2).=> Ensure that the file2 hashes to the different subvolume of file1
Step 7 to Step 8 remains same

In this scenario, sync happens as follows:
   a. If both the bricks active are (selfhealed bricks) which has recoreded MKNOD. Sync happens.
   b. If the self healed brick containing MKNOD for sticky bit file becomes PASSIVE, hardlinks are not synced. 


Version-Release number of selected component (if applicable):
=============================================================

mainline


How reproducible:
=================

Always with the above steps.

--- Additional comment from Worker Ant on 2017-07-26 08:24:07 EDT ---

REVIEW: https://review.gluster.org/17880 (geo-rep: Fix syncing of self healed hardlinks) posted (#1) for review on master by Kotresh HR (khiremat)

Comment 1 Worker Ant 2017-07-28 09:54:29 UTC
REVIEW: https://review.gluster.org/17905 (geo-rep: Fix syncing of self healed hardlinks) posted (#1) for review on release-3.12 by Kotresh HR (khiremat)

Comment 2 Worker Ant 2017-07-31 16:29:36 UTC
COMMIT: https://review.gluster.org/17905 committed in release-3.12 by Shyamsundar Ranganathan (srangana) 
------
commit 1f51ffce563f614053af689a1ee0d84e37232fa7
Author: Kotresh HR <khiremat>
Date:   Wed Jul 26 08:09:31 2017 -0400

    geo-rep: Fix syncing of self healed hardlinks
    
    Problem:
    In a distribute replicate volume, if the hardlinks
    are created when a subvolume is down, it gets
    healed from other subvolume when it comes up.
    If this subvolume becomes ACTIVE in geo-rep
    there are chances that those hardlinks won't
    be synced to slave.
    
    Cause:
    AFR can't detect hardlinks during self heal.
    It just create those files using mknod and
    the same is recorded in changelog. Geo-rep
    processes these mknod and ignores it as
    it finds gfid already on slave.
    
    Solution:
    Geo-rep should process the mknod as link
    if the gfid already exists on slave.
    
    > Change-Id: I2f721b462b38a74c60e1df261662db4b99b32057
    > BUG: 1475308
    > Signed-off-by: Kotresh HR <khiremat>
    > Reviewed-on: https://review.gluster.org/17880
    > Smoke: Gluster Build System <jenkins.org>
    > CentOS-regression: Gluster Build System <jenkins.org>
    > Reviewed-by: Aravinda VK <avishwan>
    (cherry picked from commit d685e4238fafba8f58bf01174c79cb5ca35203e5)
    
    Change-Id: I2f721b462b38a74c60e1df261662db4b99b32057
    Signed-off-by: Kotresh HR <khiremat>
    BUG: 1476208
    Reviewed-on: https://review.gluster.org/17905
    Smoke: Gluster Build System <jenkins.org>
    CentOS-regression: Gluster Build System <jenkins.org>
    Reviewed-by: Aravinda VK <avishwan>

Comment 3 Shyamsundar 2017-09-05 17:37:48 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.12.0, please open a new bug report.

glusterfs-3.12.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://lists.gluster.org/pipermail/announce/2017-September/000082.html
[2] https://www.gluster.org/pipermail/gluster-users/


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