<br><br><div class="gmail_quote">On Wed, Jun 20, 2012 at 2:50 AM, Pranith Kumar Karampuri <span dir="ltr"><<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
They are not in split-brain, I responded to your previous mail just now giving examples of split-brain.<br>
<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Avati,<br>
What should be the behavior when there is metadata split-brain?.<br></blockquote><div><br></div><div>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".</div>
<div><br></div><div>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)</div>
<div><br></div><div>Avati</div></div>