Data Structures
There are different kinds of configuration data: configuration of filesystems, services, nodes, storage devices, etc. Configuration data is contained in configuration objects of which there are following predefined types:
- m0_conf_dir (a container for configuration objects),
- m0_conf_root
- m0_conf_profile,
- m0_conf_pool,
- m0_conf_pver,
- m0_conf_objv,
- m0_conf_node,
- m0_conf_process,
- m0_conf_service,
- m0_conf_sdev,
- m0_conf_site,
- m0_conf_rack,
- m0_conf_enclosure,
- m0_conf_controller,
- m0_conf_drive,
- m0_conf_fdmi_flt_grp,
- m0_conf_fdmi_filter.
Some attributes are applicable to any type of configuration object. Such common attributes are put together into m0_conf_obj structure, which is embedded into concrete configuration objects.
DAG of configuration objects:
Enumerations
- m0_conf_status — readiness of object's configuration data.
Configuration Object Status
A configuration object exists in one of three states:
- M0_CS_MISSING — configuration data is absent and is not being retrieved; the object is a stub.
- M0_CS_LOADING — retrieval of configuration is in progress; the object is a stub.
- M0_CS_READY — configuration is available; this is a fully-fledged object, not a stub.
These values make up m0_conf_status enumeration.
Status field of a configuration object – m0_conf_obj::co_status – is accessed and modified by object's owner (confc or confd). Initial status is M0_CS_MISSING. Possible transitions are shown on the diagram below:
Pinned Objects
If object's reference counter – m0_conf_obj::co_nrefs – is non-zero, the object is said to be pinned. Stubs cannot be pinned, only M0_CS_READY objects can. Object's reference counter is used by confc and confd implementations and is not supposed to be accessed by a configuration consumer.
Private Fields
Only those fields of concrete configuration objects that follow "configuration data (for the application)" comment should ever be accessed by the application. The rest of fields are private property of confc and confd implementations.
