****************************************************************
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.
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
