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

[Ted Miller]

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