When gfapi initilizes a 'struct glfs' structure, it sets several options
to defaults. These defaults are not always suitable for all kind of
workloads, think about a large inode-table for single-file (qemu/vm)
usage. Other options are given to the FUSE client through mount-options,
but passing these through gfapi is not possible at the moment.
To resolve this, I would like to start designing a practical interface
that is modular enough so that we do not need to provide a glfs_*()
function for each option that is configurable. Below is a first idea,
and I would like feedback from others about it.
enum glfs_conf_bool {
GLFS_CONF_BOOL_MDCACHE,
GLFS_CONF_BOOL_READONLY,
...
}
int glfs_conf_set_bool (struct glfs*, enum glfs_conf_bool, bool);
int glfs_conf_get_bool (struct glfs*, enum glfs_conf_bool, bool*);
enum glfs_conf_int {
GLFS_CONF_INT_ITABLE,
GLFS_CONF_INT_PINGTIMEOUT,,
...
}
int glfs_conf_set_int (struct glfs*, enum glfs_conf_bool, int);
int glfs_conf_get_int (struct glfs*, enum glfs_conf_bool, int*);
[this only shows bool+int interfaces, others will be needed too]
This is not as flexible as I would like. It would be nicer to have a way
to discover possible options (strings?) and their values/ranges. gfapi
could walk the graph and take the 'struct volume_options options[]' from
each xlator. I'm not sure yet if this would make the approach too
complex, and welcome ideas and opinions :-)
Thanks,
Niels
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
