Re: [Gluster-devel] split brain: how should it be cured?

[Pranith Kumar Karampuri]

Raised the following bug for tracking this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=834172

Pranith
----- Original Message -----
From: "Anand Avati" <address@hidden>
To: "Pranith Kumar Karampuri" <address@hidden>
Cc: "Emmanuel Dreyfus" <address@hidden>, "Anand Avati" <address@hidden>, 
address@hidden
Sent: Thursday, June 21, 2012 10:30:08 AM
Subject: Re: [Gluster-devel] split brain: how should it be cured?




On Wed, Jun 20, 2012 at 2:50 AM, Pranith Kumar Karampuri < address@hidden > 
wrote: 


They are not in split-brain, I responded to your previous mail just now giving 
examples of split-brain. 




On the contrary, "Yesterday" example is not a split brain, but "today" example 
is a split brain. Though I'm not sure what steps you performed before you 
landed in that situation. 




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) 


Avati