> We're trying to implement a global option for NFS-Ganesha that'll look like > this, > > gluster vol set all features.ganesha on > > This is intended to disable gluster-nfs throughout the gluster trusted pool, > start NFS-Ganesha server and configure HA for NFS-Ganesha. > A dummy translator has been introduced to manage this global option and one > more volume level option. > When this translator is loaded, there has to be a client volfile > change on ALL the volumes present in the trusted pool. When *<all>* is used > instead of a volume name, > the volume set infrastructure in glusterd doesn't result in any volfile > changes. > > As per discussions with the glusterd team, we'd need a cluster-wide lock to > achieve what we require. This is required, - if this option is persisted in each of the existing volume's configuration, apart from being globally persisted. - to synchronize concurrent operations of the form, "gluster volume set all <some-global-option> <some-value>, if these operations use a common global configuration file. I would suggest you to use a single configuration file for options that are set on 'all' volumes. Modifications to this file should be protected by a cluster-wide cooperative lock (for atomicity). It must be ensured that effects associated with modifications to this option must persist when individual volumes' local configuration may be concurrently modified. e.g, if add-brick is being performed on a volume V1 Concurrently, "volume set all features.ganesha" on is issued, you must guarantee that volume V1 is also served via nfs-ganesha service, independent of the order of execution of these commands. Does that make sense? _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel