Hi, Reply inline Regards, Poornima ----- Original Message ----- > From: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx> > To: "Raghavendra Talur" <rtalur@xxxxxxxxxx> > Cc: "Poornima Gurusiddaiah" <pgurusid@xxxxxxxxxx>, "Gluster Devel" <gluster-devel@xxxxxxxxxxx>, "Jeff Cody" > <jcody@xxxxxxxxxx>, "Rajesh Joseph" <rjoseph@xxxxxxxxxx> > Sent: Monday, May 9, 2016 12:17:25 PM > Subject: Re: xlator option setting in gfapi > > > > ----- 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)? > This is what happens when glfs_set_xlator_option is called: - It updates ctx->cmd_args->xlator_options - gf_add_cmdline_options (during glusterfs_graph_prepare.. pub_glfs_init) adds it to xl->options - glusterfs_graph_unknown_options (during glusterfs_graph_activate.. pub_glfs_init) checks if the options in xl->options are present or not. If the option is not present it just logs a warning message. These options are treated as command line args. To report the option setting as a failure, at the least we can fail glfs_init(). Would that be an acceptable solution? This change will also affect bricks, fuse mount and other gluster processes. > > > > 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
