This chapter will explain how SSM interacts with various back ends, then detail some common use cases.
SSM uses a core abstraction layer in
ssmlib/main.py which complies with the device, pool, and volume abstraction, ignoring the specifics of the underlying technology. Backends can be registered in
ssmlib/main.py to handle specific storage technology methods, such as
snapshot, or to
remove volumes and pools.
There are already several backends registered in SSM. The following sections will give basic information on them as well as definitions on how they handle pools, volumes, snapshots, and devices.
BTRFS, a file system with many advanced features, is used as a volume management backend in SSM. Pools, volumes, and snapshots can be created with the BTRFS backend.
The BTRFS file system itself is the pool. It can be extended by adding more devices or shrunk by removing devices. SSM creates a BTRFS file system when a BTRFS pool is created. This means that every new BTRFS pool has one volume of the same name as the pool which cannot be removed without removing the entire pool. The default BTRFS pool name is
The name of the pool is used as the file system label. If there is already an existing BTRFS file system in the system without a label, the BTRFS pool will generate a name for internal use in the format of
Volumes created after the first volume in a pool are the same as sub-volumes. SSM will temporarily mount the BTRFS file system if it is unmounted in order to create a sub-volume.
The name of a volume is used as the subvolume path in the BTRFS file system. For example, a subvolume displays as
/dev/lvm_pool/lvol001. Every object in this path must exist in order for the volume to be created. Volumes can also be referenced with its mount point.
Snapshots can be taken of any BTRFS volume in the system with SSM. Be aware that BTRFS does not distinguish between subvolumes and snapshots. While this means that SSM cannot recognize the BTRFS snapshot destination, it will try to recognize special name formats. If the name specified when creating the snapshot does the specific pattern, the snapshot will not be recognized and instead be listed as a regular BTRFS volume.
BTRFS does not require any special device to be created on.
Pools, volumes, and snapshots can be created with LVM. The following definitions are from an LVM point of view.
LVM pool is the same as an LVM volume group. This means that grouping devices and new logical volumes can be created out of the LVM pool. The default LVM pool name is
An LVM volume is the same as an ordinary logical volume.
When a snapshot is created from the LVM volume a new
snapshot volume is created which can then be handled just like any other LVM volume. Unlike BTRFS, LVM is able to distinguish snapshots from regular volumes so there is no need for a snapshot name to match a particular pattern.
SSM makes the need for an LVM backend to be created on a physical device transparent for the user.
The crypt backend in SSM uses
dm-crypt target to manage encrypted volumes. Crypt backends can be used as a regular backend for creating encrypted volumes on top of regular block devices (or on other volumes such as LVM or MD volumes), or to create encrypted LVM volumes in a single steps.
Only volumes can be created with a crypt backend; pooling is not supported and it does not require special devices.
The following sections define volumes and snapshots from the crypt point of view.
Crypt volumes are created by
dm-crypt and represent the data on the original encrypted device in an unencrypted form. It does not support RAID or any device concatenation.
Two modes, or extensions, are supported: luks and plain. Luks is used by default. For more information on the extensions, refer to
While the crypt backend does not support snapshotting, if the encrypted volume is created on top of an LVM volume, the volume itself can be snapshotted. The snapshot can then be opened by using
15.1.4. Multiple Devices (MD)
MD backend is currently limited to only gathering the information about MD volumes in the system.