Bug 1578273 - data-mismatch after split-brain + add-brick
Summary: data-mismatch after split-brain + add-brick
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: GlusterFS
Classification: Community
Component: replicate
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ravishankar N
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-15 07:25 UTC by Ravishankar N
Modified: 2018-11-20 06:17 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-20 06:17:28 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Ravishankar N 2018-05-15 07:25:39 UTC
Description of problem:
    When add-brick is performed on a replica 2 subvolume that has a file in
    data split-brain, the current logic for post-op failure accounting
    (originally added to fix spurious cyclic split-brains) picks up one of
    the 2 bricks as source, heals it into the newly added brick and resets the
    afr xattrs on  all 3 bricks. But the brick that was not chosen as source will
    still have different contents leading to silent data mismatch. The same
    problem is there even for metadata split-brain.

Comment 1 Ravishankar N 2018-05-15 07:31:31 UTC
https://review.gluster.org/#/c/20023/

Comment 2 Worker Ant 2018-05-15 07:31:32 UTC
REVIEW: https://review.gluster.org/20023 (afr: do not heal split-brain on add-brick) posted (#1) for review on master by Ravishankar N

Comment 3 Ravishankar N 2018-11-20 06:17:28 UTC
Closing the bug for now as the patch doesn't fully solve the problem and I'm not working on the complete fix at the moment.


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