Gluster users - Feb 2015 - ... i was able to produce a split brain...

>
> ****************************************************************
> That brought another thought to mind (have not had reason to try it):
> 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.
>
> *****************************************************************
> A not-officially-sanctioned way that I dealt with a split-brain a few 
> versions back:
> 1. decided I wanted to keep file on host-2
> 2. log onto host-2
> 3. cp /brick/data1/hair-pulling.txt /gluster/data1/hair-pulling.txt-dud
> 4. rm /brick/data1/hair-pulling.txt
> 5. follow some Joe Julian blog stuff to delete the "invisible
fork" of
> file
> 6. gluster volume heal data1 all
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.

On 2/3/2015 12:23 PM, Joe Julian wrote:
>> ****************************************************************
>> That brought another thought to mind (have not had reason to try it):
>> 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.
> 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. 
Joe, I moved you comments up to be closest to the proposal they seem relevant
to.
>>
>> *****************************************************************
>> A not-officially-sanctioned way that I dealt with a split-brain a few 
>> versions back:
>> 1. decided I wanted to keep file on host-2
>> 2. log onto host-2
>> 3. cp /brick/data1/hair-pulling.txt /gluster/data1/hair-pulling.txt-dud
>> 4. rm /brick/data1/hair-pulling.txt
>> 5. follow some Joe Julian blog stuff to delete the "invisible
fork" of file
>> 6. gluster volume heal data1 all
If you note, in the above scenario I copied from the brick to the mounted 
gluster volume.  I believe that this forces the breaking of any linkage 
between the old file and the new one.  Am I missing something there?

Ted Miller
Elkhart, IN