Motr
M0
|
DLD of configuration schema. More...
Macros | |
#define | M0_CFG_SDEV_INTERFACE_TYPE_IS_VALID(dtype) (0 < (dtype) && (dtype) < M0_CFG_DEVICE_INTERFACE_NR) |
#define | M0_CFG_SDEV_MEDIA_TYPE_IS_VALID(dtype) (0 < (dtype) && (dtype) < M0_CFG_DEVICE_MEDIA_NR) |
#define | M0_CONF_SERVICE_TYPES |
Enumerations | |
enum | m0_cfg_state_bit { M0_CFG_STATE_ONLINE = 1 << 0, M0_CFG_STATE_GOOD = 1 << 1 } |
enum | m0_cfg_flag_bit { M0_CFG_FLAG_REAL = 1 << 0, M0_CFG_FLAG_LITTLE_ENDIAN = 1 << 1, M0_CFG_FLAG_REMOVABLE = 1 << 2 } |
enum | m0_cfg_nic_type { M0_CFG_NIC_ETHER10 = 1, M0_CFG_NIC_ETHER100, M0_CFG_NIC_ETHER1000, M0_CFG_NIC_ETHER10GB, M0_CFG_NIC_INFINIBAND } |
enum | m0_cfg_storage_device_interface_type { M0_CFG_DEVICE_INTERFACE_ATA = 1, M0_CFG_DEVICE_INTERFACE_SATA, M0_CFG_DEVICE_INTERFACE_SCSI, M0_CFG_DEVICE_INTERFACE_SATA2, M0_CFG_DEVICE_INTERFACE_SCSI2, M0_CFG_DEVICE_INTERFACE_SAS, M0_CFG_DEVICE_INTERFACE_SAS2, M0_CFG_DEVICE_INTERFACE_NR } |
enum | m0_cfg_storage_device_media_type { M0_CFG_DEVICE_MEDIA_DISK = 1, M0_CFG_DEVICE_MEDIA_SSD, M0_CFG_DEVICE_MEDIA_TAPE, M0_CFG_DEVICE_MEDIA_ROM, M0_CFG_DEVICE_MEDIA_NR } |
enum | { M0_CFG_PARAM_LEN = 128 } |
enum | m0_conf_service_type { M0_CST_NR } |
Functions | |
M0_INTERNAL const char * | m0_conf_service_type2str (enum m0_conf_service_type type) |
static bool | m0_conf_service_type_is_valid (enum m0_conf_service_type t) |
Variables | |
enum m0_cfg_state_bit | M0_XCA_ENUM |
DLD of configuration schema.
This file defines the interfaces and data structures to store and access the Motr configuration information in database. Motr configuration information is used to describe how a Motr file system is organized by storage, nodes, devices, containers, services, etc.
These data structures are used for on-disk purpose.
This DLD contains the data structures and routines to organize the configuration information of Motr, to access these information. These configuration information is stored in database, and is populated to clients and servers who are using these information to take the whole Motr system up. These information is cached on clients and servers. These information is treated as resources, which are protected by locks. So configuration may be invalidated and re-acquired (that is update) by users when resources are revoked.
The configuration schema is to provide a way to store, load, and update these informations. How to maintain the relations in-between these data strucctures is done by its upper layer.
#define M0_CFG_SDEV_INTERFACE_TYPE_IS_VALID | ( | dtype | ) | (0 < (dtype) && (dtype) < M0_CFG_DEVICE_INTERFACE_NR) |
#define M0_CFG_SDEV_MEDIA_TYPE_IS_VALID | ( | dtype | ) | (0 < (dtype) && (dtype) < M0_CFG_DEVICE_MEDIA_NR) |
#define M0_CONF_SERVICE_TYPES |
Type of Motr service.
anonymous enum |
enum m0_cfg_flag_bit |
enum m0_cfg_nic_type |
enum m0_cfg_state_bit |
Motr device interface types.
enum m0_conf_service_type |
M0_INTERNAL const char* m0_conf_service_type2str | ( | enum m0_conf_service_type | type | ) |
|
inlinestatic |
enum m0_conf_service_type M0_XCA_ENUM |