Gluster users - Feb 2015 - ... i was able to produce a 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

On 02/03/2015 11:34 AM, Ted Miller wrote:
>
> 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?
Yep, I missed that. I seem to be suffering from split-brain, myself, today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20150203/cef35a5b/attachment.html>