For basic test and evaluation purposes it may not always be practical or possible to allocate physical disk devices on a cluster to Mayastor for use within its Pools. As a convenience, Mayastor supports two disk device type emulations for this purpose:
Memory-Backed Disks ("RAM drive")
Memory-backed Disks are the most readily provisioned, since Mayastor will automatically create and configure them as it creates the corresponding pool. However they are the least durable option - since the data is held entirely within memory allocated to a Mayastor pod, should that pod be terminated and rescheduled by Kubernetes, that data will be lost. Therefore it is strongly recommended that this type of disk emulation be used only for short duration, simple testing. It must not be considered for production use-cases.
File-backed disks, as their name suggests, store pool data within a file held on a file system which is accessible to the Mayastor pod hosting that pool. Their durability depends on how they are configured; specifically on which type of volume mount they are located. If located on a path which uses Kubernetes ephemeral storage (eg. EmptyDir), they may be no more persistent than a RAM drive would be. However if placed on their own Persistent Volume (eg. a Kubernetes Host Path volume) then they may considered 'stable'. They are slightly less convenient to use than Memory-backed disks, in that the backing files must be created by the user as a separate step preceding pool creation. However File-backed disks can be significantly larger than RAM disks as they consume considerably less memory resource within the hosting Mayastor pod.
Creating a memory-backed disk emulation entails using the "malloc" uri scheme within the Mayastor pool CRD.
apiVersion: "openebs.io/v1alpha1"kind: MayastorPoolmetadata:name: mempool-1namespace: mayastorspec:node: worker-node-1disks: ["malloc:///malloc0?size_mb=64"]
The example shown defines a pool named "mempool-1". The Mayastor pod hosted on "worker-node-1" automatically creates a 64MiB emulated disk for it to use, with the device identifier "malloc0" - provided that at least 64MiB of 2MiB-sized Huge Pages are available to that pod after the Mayastor container's own requirements have been satisfied.
The Mayastor Pool CRD accepts URIs matching the malloc:/// schema within its
disks field for the purposes of provisioning memory-based disks. The general format is:
Where <DeviceId> is an integer value which uniquely identifies the device on that node and the parameter collection <parameters> may include the following:
Specifies the requested size of the device in MiB
Mutually exclusive with "num_blocks"
Specifies the requested size of the device in terms of the number of addressable blocks
Mutually exclusive with "size_mb"
Specifies the block size to be reported by the device in bytes
Integer (512 or 4096)
Optional. If not used, block size defaults to 512 bytes
Mayastor can use file-based disk emulation in place of physical pool disk devices, by employing the aio:/// URI schema within the pool's declaration in order to identify the location of the file resource.
apiVersion: "openebs.io/v1alpha1"kind: MayastorPoolmetadata:name: filepool-1namespace: mayastorspec:node: worker-node-1disks: ["aio:///var/tmp/disk1.img"]
apiVersion: "openebs.io/v1alpha1"kind: MayastorPoolmetadata:name: filepool-1namespace: mayastorspec:node: worker-node-1disks: ["aio:///tmp/disk1.img?blk_size=4096"]
The examples shown seek to create a pool using a file named "disk1.img", located in the /var/tmp directory of the Mayastor container's file system, as its member disk device. For this operation to succeed, the file must already exist on the specified path (which should be FULL path to the file) and this path must be accessible by the Mayastor pod instance running on the corresponding node.
The aio:/// schema requires no other parameters but optionally, "blk_size" may be specified. Block size accepts a value of either 512 or 4096, corresponding to the emulation of either a 512-byte or 4kB sector size device. If this parameter is omitted the device defaults to using a 512-byte sector size.
File-based disk devices are not over-provisioned; to create a 10GiB pool disk device requires that a 10GiB-sized backing file exist on a file system on an accessible path.
The preferred method of creating a backing file is to use the linux
truncate command. The following illustration demonstrates the creation of a 1GiB-sized file named disk1.img within the directory /tmp.
truncate -s 1G /tmp/disk1.img