Chapter 15. System Storage Manager (SSM)

System Storage Manager (SSM) provides a command line interface to manage storage in various technologies. Storage systems are becoming increasingly complicated through the use of Device Mappers (DM), Logical Volume Managers (LVM), and Multiple Devices (MD). This creates a system that is not user friendly and makes it easier for errors and problems to arise. SSM alleviates this by creating a unified user interface. This interface allows users to run complicated systems in a simple manner. For example, to create and mount a new file system without SSM, there are five commands that must be used. With SSM only one is needed.
This chapter will explain how SSM interacts with various back ends, then detail some common use cases.

15.1. SSM Backends

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 create, 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.

15.1.1. BTRFS Backend

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.

15.1.1.1. BTRFS Pool

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 btrfs_pool.
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 btrfs_device_base_name.

15.1.1.2. BTRFS Volume

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.

15.1.1.3. BTRFS Snapshot

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.

15.1.1.4. BTRFS Device

BTRFS does not require any special device to be created on.

15.1.2. LVM Backend

Pools, volumes, and snapshots can be created with LVM. The following definitions are from an LVM point of view.

15.1.2.1. LVM Pool

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 lvm_pool.

15.1.2.2. LVM Volume

An LVM volume is the same as an ordinary logical volume.

15.1.2.3. LVM Snapshot

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.

15.1.2.4. LVM Device

SSM makes the need for an LVM backend to be created on a physical device transparent for the user.

15.1.3. Crypt

The crypt backend in SSM uses cryptsetup and 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.

15.1.3.1. Crypt Volume

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 man cryptsetup.

15.1.3.2. Crypt Snapshot

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 cryptsetup.

15.1.4. Multiple Devices (MD)

MD backend is currently limited to only gathering the information about MD volumes in the system.