Re: Global option for nfs-ganesha

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yes, it does. Thank you so much.

Meghana

----- Original Message -----
From: "Krishnan Parthasarathi" <kparthas@xxxxxxxxxx>
To: "Meghana Madhusudhan" <mmadhusu@xxxxxxxxxx>
Cc: gluster-devel@xxxxxxxxxxx, "Niels de Vos" <ndevos@xxxxxxxxxx>
Sent: Thursday, January 22, 2015 10:18:49 AM
Subject: Re: Global option for nfs-ganesha




> 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




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux