[Gluster-devel] solutions for split brain situation

[Mark Mielke]

On 09/15/2009 07:45 PM, Michael Cassaniti wrote:
> Don't try bypassing the mountpoint to perform file operations _period_ 
> . You can always have a replicate mountpoint configured on the server 
> (i.e. a client for replicate), as well as the server side. NFS should 
> run on top of this replicate mountpoint. This (poor) graphic may help. 
> Note that everything is running on the same machine:

Agree. The main feature of GlusterFS in this regard has to do with read 
- not write. It is very cool that if GlusterFS with cluster/replicate 
completely fails, the backing store is still accessible to recover from. 
However, this is not a license to write or re-write the backing story as 
we see fit. It should be treated as read-only if it is used at all.

Note that even read-only does not work if one starts to use the 
BerkeleyDB storage method, distribute, or stripe.

In any case - dropping extended attributes for a system that relies on 
extended attributes is a lossy backup, and should be expected to be 
invalid if restored into place. Even if the extended attributes are kept 
in the backup - I think it only decreases the risk, it does not 
eliminate it. Writes really should not bypass the mount point.

Cheers,
mark

-- 
Mark Mielke<mark at mielke.cc>