<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 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.<br>
</body>
</html>