Bug 834172 - Conservative merge for meta-data split-brain
Summary: Conservative merge for meta-data split-brain
Keywords:
Status: CLOSED EOL
Alias: None
Product: GlusterFS
Classification: Community
Component: replicate
Version: pre-release
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Pranith Kumar K
QA Contact:
URL:
Whiteboard: FutureFeature
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-21 06:08 UTC by Pranith Kumar K
Modified: 2015-10-22 15:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-22 15:40:20 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Pranith Kumar K 2012-06-21 06:08:49 UTC
Description of problem:

    Avati,
      What should be the behavior when there is metadata split-brain?.


While we are doing mostly the right thing in terms of detecting a syntactic conflict in meta data (and calling it "split brain"), we are doing nothing at all in terms of merging/resolving conflicts. Unlike data, there are more interesting possibilities with POSIX metadata w.r.t semantic merge/resolution. The entire problem boils down to basically two attributes - permission and ownership. Rest of the attributes are either non-modifiable as "meta data" (st_blocks, st_ctime etc.) or we don't care (e.g st_atime). We can provide a few merge policy options if we detect meta data conflict, like - "apply the most conservative permission", "apply most conservative permission ignoring the execute bit", "change ownership to owner of parent directory", "change ownership to root".

At the very least we need to support a very basic semantic merge - if copies are accidentally identical, consider the conflict resolved. And this needs to be done for both meta data and data (and possibly extended to GFID mismatch as well)
Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Jeff Darcy 2012-10-31 13:13:53 UTC
Kind of an enhancement request, which would normally be low severity, but this seems like a pretty important thing to add.

Comment 2 Kaleb KEITHLEY 2015-10-22 15:40:20 UTC
pre-release version is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.


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