How to Configure RHEL 9 Stratis Storage Pools for Thin-Provisioned Cryptographic Block Devices

Historically, managing advanced storage features on Red Hat Enterprise Linux (RHEL)—such as thin provisioning, snapshotting, and block-level encryption—required systems administrators to master a complex stack of disjointed utilities. You had to manually partition disks with parted, configure LUKS encryption with cryptsetup, create physical volumes and volume groups with LVM, format with XFS, and manage mount points in /fstab. A single mistake could result in catastrophic data loss. To simplify this, RHEL 9 introduces Stratis, a unified local storage management daemon. By utilizing Stratis, administrators can rapidly deploy thin-provisioned, dynamically scaling file systems on top of hardware-encrypted block devices with just a few declarative commands.

The Architecture of Stratis

Stratis is not a new filesystem. It is a volume-managing filesystem that acts as an orchestration layer on top of existing, battle-tested Linux subsystems (specifically Device Mapper and the XFS filesystem).

Stratis utilizes the concept of “Pools.” You add raw block devices (like SSDs, NVMe drives, or iSCSI LUNs) to a Stratis Pool. Stratis amalgamates this capacity. You then carve “Filesystems” out of this pool. Crucially, Stratis filesystems are implicitly thin-provisioned. If you have a 10TB pool and create a Stratis filesystem, it does not reserve any space upfront. It dynamically expands as data is written, up to the physical limits of the underlying pool. This eliminates the need to aggressively estimate partition sizes during server deployment.

Installing the Stratis Daemon

Stratis operates as a background daemon (stratisd) which communicates via a D-Bus API, and a command-line interface (stratis-cli). Install the required packages on your RHEL 9 server:

sudo dnf install stratis-cli stratisd
sudo systemctl enable --now stratisd

Configuring Encrypted Block Devices

Before adding raw disks (e.g., /dev/sdb and /dev/sdc) to a Stratis pool, security policies often mandate data-at-rest encryption. While you can use LUKS manually, Stratis natively supports the Kernel Keyring to manage LUKS2 encryption transparently.

First, you must capture the encryption passphrase and load it into the kernel keyring so the Stratis daemon can access it. In a production environment, this key would typically be fetched via Clevis and Tang for network-bound disk encryption (NBDE), but for this example, we will inject it manually.

# Create a secure keyfile
echo -n "SuperSecretEncryptionKey123!" > /root/stratis_key
chmod 600 /root/stratis_key

# Load the key into the kernel keyring under the description "stratis-pool-key"
sudo stratis key set --capture-key stratis-pool-key < /root/stratis_key

Creating the Encrypted Stratis Pool

With the key residing in the kernel keyring, you can initialize the Stratis pool using the raw block devices, explicitly instructing Stratis to encrypt them using the loaded key.

sudo stratis pool create --key-desc stratis-pool-key secure_data_pool /dev/sdb /dev/sdc

Stratis automatically formats the block devices with LUKS2, unlocks them using the keyring, and amalgamates their unencrypted capacities into secure_data_pool. You can verify the pool’s topology and encryption status:

sudo stratis pool list
sudo stratis blockdev list secure_data_pool

Carving Out Thin-Provisioned Filesystems

Creating a filesystem within the pool is instantaneous because of thin provisioning.

sudo stratis filesystem create secure_data_pool app_data
sudo stratis filesystem create secure_data_pool log_data

Stratis automatically formats these virtual block devices with the XFS filesystem. You do not need to specify sizes; they share the underlying pool capacity dynamically.

Mounting and Persistence

Stratis exposes the dynamic filesystems under /dev/stratis/<pool_name>/<fs_name>. You can mount them identically to standard block devices.

sudo mkdir -p /mnt/app_data
sudo mount /dev/stratis/secure_data_pool/app_data /mnt/app_data

To ensure the encrypted pool survives a reboot, you must configure /etc/fstab using the UUID of the filesystem, and append the x-systemd.requires=stratisd.service mount option so systemd knows to wait for the Stratis daemon to initialize and unlock the LUKS devices before attempting to mount the XFS file systems.

By abstracting the complexity of LVM, LUKS, and XFS into a unified interface, Stratis allows Linux administrators to deploy robust, encrypted, and dynamically scaling storage infrastructure in seconds, drastically reducing the margin for catastrophic configuration errors.