<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 2/3/2015 2:44 PM, Joe Julian wrote:<br>
    </div>
    <blockquote cite="mid:54D12521.5000409@julianfamily.org" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <br>
      <div class="moz-cite-prefix">On 02/03/2015 11:34 AM, Ted Miller
        wrote:<br>
      </div>
      <blockquote cite="mid:54D122BA.3080201@sonsetsolutions.org"
        type="cite"> <br>
        On 2/3/2015 12:23 PM, Joe Julian wrote: <br>
        <br>
        <blockquote type="cite">
          <blockquote type="cite">****************************************************************

            <br>
            That brought another thought to mind (have not had reason to
            try it): <br>
            How does gluster cope if you go behind its back and rename a
            "rejected" file?  For instance, in my example above, what if
            I go directly on the brick and rename the host-2 copy of the
            file to hair-pulling.txt-dud?  The ideal scenario would seem
            to be that if user does a heal it would treat the copy as
            new file, see no dupe for hair-pulling.txt, and create a new
            dupe on host-2.  Since hair-pulling.txt-dud is also a new
            file, a dupe would be created on host-1.  User could then
            access files, verify correctness, and then delete
            hair-pulling.txt-dud. <br>
          </blockquote>
          This should cause you to have two files with the same gfid.
          This will create the hardlink in .glusterfs again, and the
          heal will then re-create the .txt file also with that same
          gfid. Since both files will have the same gfid (stored in
          extended attributes) and be hard linked to the same file under
          .glusterfs you should then end up with both files being
          split-brain. </blockquote>
        Joe, I moved you comments up to be closest to the proposal they
        seem relevant to. <br>
        <blockquote type="cite">
          <blockquote type="cite"> <br>
            *****************************************************************

            <br>
            A not-officially-sanctioned way that I dealt with a
            split-brain a few versions back: <br>
            1. decided I wanted to keep file on host-2 <br>
            2. log onto host-2 <br>
            3. cp /brick/data1/hair-pulling.txt
            /gluster/data1/hair-pulling.txt-dud <br>
            4. rm /brick/data1/hair-pulling.txt <br>
            5. follow some Joe Julian blog stuff to delete the
            "invisible fork" of file <br>
            6. gluster volume heal data1 all <br>
          </blockquote>
        </blockquote>
        If you note, in the above scenario <u>I copied from the brick
          to the mounted gluster volume</u>.  I believe that this forces
        the breaking of any linkage between the old file and the new
        one.  Am I missing something there? <br>
      </blockquote>
      Yep, I missed that. I seem to be suffering from split-brain,
      myself, today.</blockquote>
    Don't sweat it, your blog posts have dug me out of more than one
    hole.<br>
    <br>
    Ted Miller<br>
    Elkhart, IN, USA<br>
    <br>
    <blockquote cite="mid:54D12521.5000409@julianfamily.org" type="cite">.<br>
    </blockquote>
    <i></i>
  </body>
</html>