----- Original Message ----- > From: "Raghavendra Talur" <rtalur@xxxxxxxxxx> > To: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx> > Cc: "Poornima Gurusiddaiah" <pgurusid@xxxxxxxxxx>, "Gluster Devel" <gluster-devel@xxxxxxxxxxx>, "Jeff Cody" > <jcody@xxxxxxxxxx>, "Rajesh Joseph" <rjoseph@xxxxxxxxxx> > Sent: Monday, May 9, 2016 11:57:44 AM > Subject: Re: xlator option setting in gfapi > > On Mon, May 9, 2016 at 8:45 AM, Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx> > wrote: > > > Hi Poornima/Raghavendra, > > > > This mail is an initiation of a thread to discuss how to make xlator > > options setting in gfapi synchronous (so, that caller will know the result) > > or providing a cbk to let the application know about the status. > > > > My very naive attempt of code-reading showed me that > > pub_glfs_set_xlator_option just adds the option to cmd_args.xlator_options. > > Can you please explain how/when these values are communicated to glusterd > > to change volfile? From there we can carry forward the conversation. > > > > > Raghavendra, > > glfs_set_xlator_option is equivalent to --xlator-option of mount.glusterfs > of FUSE. This feature is not intended to apply the setting to the volume > permanently, rather it is specific to the mount and only valid for its > lifetime. > The current architecture of Gluster graph takes these options only in > cmd_args and then these values are given preference over whatever comes in > volfile from Glusterd. In essence, these settings can be used to override > the volume settings for a particular mount. For this use case, even a way to modify the options for a single mount is fine. But the problem is, how do I know whether the option I set has taken effect? Is checking return value of pug_glfs_set_xlator_option is sufficient (seems unlikely as I don't see any xlators being involved here)? Can you explain the mechanism involved here (as in how this option is propagated to relevant xlator - do we call reconfigure with new set of option dict etc)? > > If the requirement is to set a volume wide option then glusterd or one of > the REST interfaces for Glusterd should be used. > > I will also reply to the other thread with possible methods on overcoming > the problem with write-behind and qemu. > > Thanks, > Raghavendra Talur > > > > regards, > > Raghavendra > > > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel