On Wed, Apr 12, 2017 at 06:02:16PM +0530, Soumya Koduri wrote: > Hi Frank, > > We ran into an issue with using dynamic export options update using > "UpdateExport" dbus signal. This dbus signal invokes > update_export_param() which shall update all the related export > parameters in memory dynamically. But there are few options which each > FSAL may choose to store in its local structure variables (like for eg., > for ACL I see FSAL_GLUSTER storing the option value as > glfs_export->acl_enabled and FSAL_GPFS has use_acl). These local > structure variables seem to be getting updated only while creating the > export but do not get changed with dynamic options update. > > To address this, either > * we could modify FSALs to not have a local copy but read these export > parameters always from op_ctx->export (or) > * have a new FSAL api (maybe update_exports - which is no op by default) > to be invoked as part of update_export_param() and FSALs can choose to > extend it to update their local structure values.
Currently Gluster through gfapi does not allow you to change many parameters (compared to mounting a Gluster volume with FUSE). I hope to make this possible in the (relatively) near future. In that case, enabling or disabling ACLs might benefit from calling a function like glfs_option_set_bool(struct glfs*, GLFS_OPTION_ACL, onoff) When you consider this possibility, I guess an update_export() FSAL API is the best approach. But, I'm unsure what options would need to be allowed for changing during runtime... ACL might not be a great example for this, but you might be able to come up with others? HTH, Niels
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Nfs-ganesha-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
