RE: [Gluster-devel] solutions for split brain situation

[Gordan Bobic]

>> 1) There is a race condition in what you describe. Since you mentioned 30 
>> years in development, I assume you know what that means. Consider this:
>> You are "locally feeding" file "x" on server1. During this, the same file 
>> gets created via the mountpoint on server2. What would you expect to happen, 
>> in a fs that aims for full posix compliance on atomic operations?

> Sorry for a simple logic I took for granted: if I create a file on a fs and
> the fs finds I can do that, I feel ok. If glusterfsd creates a file on a fs
> and the fs tells it it is ok, it should. We cannot meet at the same time,
> because there is no "same time" for fs requests. First request will win.
> My hope is that glusterfs is not "creating" files on the client side without
> having checked the backend storage for their existence or absence.
> Is that assumption incorrect?
 
Which backend? There could be many servers. Gluster will check parent directory 
journal to make sure it is consistent, lock, write, unlock. Checking and 
comparing the whole directory content would be prohibitively expensive, 
especially for large directories over a WAN.

> > 2) The example you give doesn't, in any way, provide justification for not 
> > copying the file in via the mountpoint in the first place.

> Read again: I said "and not going over glusterfs for some unknown reason." 
> "unkown reason" means that I can think of some for myself but tend to believe
> there may be lots of others. My personal reason nr 1 is the soft migration
> situation.

See my comment about writing a program to set up the xattr metadata for you