[Gluster-users] ... i was able to produce a split brain...

[Joe Julian]

>
> ****************************************************************
> 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.