[GEDI] The need for a configuration interface in gfapi

[Niels de Vos]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/integration/attachments/20170302/68e36f74/attachment.sig>