The Logical Volumes library is a flexible storage space management system. It provides creating and managing virtual block devices with variable size. The SPDK Logical Volume library is built on top of Blobstore Programmer's Guide.
A logical volume store uses the super blob feature of blobstore to hold uuid (and in future other metadata). Blobstore types are implemented in blobstore itself, and saved on disk. An lvolstore will generate a UUID on creation, so that it can be uniquely identified from other lvolstores. By default when creating lvol store data region is unmapped. Optional –clear-method parameter can be passed on creation to change that behavior to writing zeroes or performing no operation.
A logical volume is implemented as an SPDK blob created from an lvolstore. An lvol is uniquely identified by its UUID. Lvol additional can have alias name.
Representation of an SPDK block device (spdk_bdev) with an lvol implementation. A logical volume block device translates generic SPDK block device I/O (spdk_bdev_io) operations into the equivalent SPDK blob operations. Combination of lvol name and lvolstore name gives lvol_bdev alias name in a form "lvs_name/lvol_name". block_size of the created bdev is always 4096, due to blobstore page size. Cluster_size is configurable by parameter. Size of the new bdev will be rounded up to nearest multiple of cluster_size. By default lvol bdevs claim part of lvol store equal to their set size. When thin provision option is enabled, no space is taken from lvol store until data is written to lvol bdev. By default when deleting lvol bdev or resizing down, allocated clusters are unmapped. Optional –clear-method parameter can be passed on creation to change that behavior to writing zeroes or performing no operation.
Thin provisioned lvols rely on dynamic cluster allocation (e.g. when the first write operation on a cluster is performed), only space required to store data is used and unallocated clusters are obtained from underlying device (e.g. zeroes_dev).
Sample write operations of thin provisioned blob are shown on the diagram below:
Sample read operations and the structure of thin provisioned blob are shown on the diagram below:
Logical volumes support snapshots and clones functionality. User may at any given time create snapshot of existing logical volume to save a backup of current volume state. When creating snapshot original volume becomes thin provisioned and saves only incremental differences from its underlying snapshot. This means that every read from unallocated cluster is actually a read from the snapshot and every write to unallocated cluster triggers new cluster allocation and data copy from corresponding cluster in snapshot to the new cluster in logical volume before the actual write occurs.
The read operation is performed as shown in the diagram below:
The write operation is performed as shown in the diagram below:
User may also create clone of existing snapshot that will be thin provisioned and it will behave in the same way as logical volume from which snapshot is created. There is no limit of clones and snapshots that may be created as long as there is enough space on logical volume store. Snapshots are read only. Clones may be created only from snapshots or read only logical volumes.
A snapshot can be removed only if there is a single clone on top of it. The relation chain will be updated accordingly. The cluster map of clone and snapshot will be merged and entries for unallocated clusters in the clone will be updated with addresses from the snapshot cluster map. The entire operation modifies metadata only - no data is copied during this process.
With the external snapshots feature, clones can be made of any bdev. These clones are commonly called esnap clones. Esnap clones work very similarly to thin provisioning. Rather than the back device being an zeroes device, the external snapshot bdev is used as the back device.
A bdev that is used as an external snapshot cannot be opened for writing by anything else so long as an esnap clone exists.
A bdev may have multiple esnap clones and esnap clones can themselves be snapshotted and cloned.
Blobs can be inflated to copy data from backing devices (e.g. snapshots) and allocate all remaining clusters. As a result of this operation all dependencies for the blob are removed.
Blobs can be decoupled from their parent blob by copying data from backing devices (e.g. snapshots) for all allocated clusters. Remaining unallocated clusters are kept thin provisioned. Note: When decouple is performed, only single dependency is removed. To remove all dependencies in a chain of blobs depending on each other, multiple calls need to be issued.
There is no static configuration available for logical volumes. All configuration is done through RPC. Information about logical volumes is kept on block devices.
RPC regarding lvolstore:
RPC regarding lvol and spdk bdev: