I'd prefer option 1, at this point. Saving config in multiple places is likely to cause more of these issues. If, at some point, we need option 2, we could add it then.
Daniel On 04/12/2017 08:32 AM, 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. > > Kindly share your inputs. > > Thanks, > Soumya > > ------------------------------------------------------------------------------ > 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 > Nfs-ganesha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > ------------------------------------------------------------------------------ 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 Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
