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