Overview

System Storage Manager is a single command line tool for managing Linux storage, whichever technology happens to be implementing it underneath.

The problem it addresses is that a storage stack on Linux is rarely one thing. There is Device Mapper at the bottom, LVM on top of it, perhaps software RAID or dm-crypt somewhere in the middle, and a file system on top of all of it. Every layer has its own tool, its own vocabulary and its own idea of a sensible default. Creating a volume, putting a file system on it and mounting it is four commands from four different tools, and the order they run in matters.

SSM puts one interface in front of that. It does not replace lvm, mkfs or cryptsetup, it works out which of them to call and calls them in the right order.

252 commits · 17,810 insertions(+) · 3,291 deletions(-)

From SSM’s own documentation:

System Storage Manager provides an easy to use command line interface to manage your storage using various technologies like LVM, btrfs, encrypted volumes and more.

The model

Storage on Linux is a stack of interdependent layers, so SSM models it as four kinds of object and maps them onto whatever the backend calls them:

  • Pools - groups of devices, such as LVM volume groups or the devices making up a btrfs file system
  • Volumes - units carved out of a pool: logical volumes, subvolumes, encrypted devices
  • Snapshots - point-in-time copies, where the backend supports them
  • Devices - the physical devices a pool is built from

Backends

SSM supports several backend implementations:

  • LVM - pools are volume groups, volumes are logical volumes, snapshots use LVM snapshotting
  • Btrfs - pools are btrfs file systems and volumes are subvolumes, which fits neatly because btrfs already does its own volume management
  • Crypt - encrypted volumes through dm-crypt and cryptsetup, with no pooling
  • MD and Multipath - enumeration only

That last one is the honest limit of the abstraction. MD and Multipath could be listed but never managed. Management was planned and never got written.

This backend architecture lets SSM offer a uniform command set regardless of the stack underneath.

Commands

SSM exposes a rich CLI with commands like:

  • ssm list - what is actually on the system: devices, pools, volumes, file systems, snapshots
  • ssm create - create a volume, optionally with a file system and a RAID level
  • ssm resize - grow or shrink a volume and the file system on it
  • ssm snapshot - snapshot a volume, where the backend supports it
  • ssm mount - mount a volume
  • ssm migrate - move data between devices
  • ssm check - run the file system checker

The interface gives a consistent experience so scripts and admins can learn one tool, not many.

Why it was useful

It knows what order things go in. Growing an LVM volume means extending the logical volume and then the file system. Shrinking means the same two steps in the opposite order, and getting that backwards truncates a file system that still has data in it. ssm resize is one command either way.

It looks before it acts. SSM inspects the existing layout and performs only the steps that are actually missing, rather than assuming it starts from nothing.

It is one tool to learn. The commands are the same whether the pool underneath is LVM or btrfs, which matters most to the people who touch storage occasionally and do not have the layer-specific flags memorized.

Status

SSM had several backends and a regression test suite, and it is no longer under active development. I handed it over to a colleague when I moved on to other work. Red Hat deprecated it and removed it in later releases, RHEL 9 among them.

Storage management on Linux did not get any simpler in the meantime. The tooling just moved elsewhere.

Learn more

Full documentation, usage examples and downloads are on the project site: https://system-storage-manager.github.io/