[Gluster-devel] solutions for split brain situation

[Anand Avati]

> please allow to ask a general question regarding data feed for
> glusterfs-exported files: Is it valid to bring new files to a subvolume over
> the local fs and not the glusterfs mounting client?
> The question targets the very start of a glusterfs setup. Does a user have to
> start with a (i.e. all) completely empty subvolume(s) or can he (just like
> with nfs) simply export and already existing bunch of files and dirs?
> Obviously we are only talking about replicate setups for the moment.
> Does glusterfs handle a situation correctly where some new file simply shows
> up on the first subvolume (maybe because the user copied it on the local
> servers' fs)? Does it need extended attribs set somehow from the very
> beginning, or can it simply accept a file that has currently none set and just
> use it?

You always need to copy in data from the mountpoint. glusterfs does
not support working over existing data. Because of the additional
restrictions glusterfs imposes on the backend maintenance, it is just
not feasible to support concurrent access to the backend as well as
from the mountpoint.

> Keep in mind that the user expects that glusterfs works somehow
> straight forward just like nfs. If you have to begin with exported subvolumes
> all being empty you will have a lot more troubles in migration to glusterfs.

The user is having a wrong expectation. glusterfs has never meant to
be a seamless replacement for NFS. The purpose of goals of NFS are
very different from glusterfs. It so happens that glusterfs uses an
existing disk filesystem as a backend, and so does NFS. But NFS is
_supposed_ to work fine with concurrent server side access. glusterfs
on the other hand has never claimed such a support, nor do we intend
to support this use case anytime soon. As an analogy, accessing the
backend export of glusterfs directly is to be considered as risky as
accessing the block layer of a disk filesystem.

With regard to existing data, the user is expected to create empty
backend exports and populate it completely from the mountpoint. All
our examples in our documentation speak about starting from empty
volumes. Working over existing backends data is not supported. One
optimization you can do for migration is to have a mountpoint on the
same machine as the server so that the moving-in happens locally for
one of the copies. The other copy has to go through the network in any
case.

If the user wants to start with a pre-filled backend export, she is at
her own risk and is using the software in an unsupported mode of
operation.

Avati