> 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
