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@xxxxxxxxx>
