[Bugs] [Bug 1475308] [geo-rep]: few of the self healed hardlinks on master did not sync to slave

bugzilla at redhat.com bugzilla at redhat.com
Wed Jul 26 12:22:53 UTC 2017


https://bugzilla.redhat.com/show_bug.cgi?id=1475308

Kotresh HR <khiremat at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
             Blocks|1417151                     |
           Assignee|bugs at gluster.org            |khiremat at redhat.com



--- Comment #1 from Kotresh HR <khiremat at redhat.com> ---

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.

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