Stratis.
a managed pool, a filesystem, and an instant snapshot.

The last ticket in the queue. A proof of concept for Stratis as a modern alternative to LVM plus XFS: build a pool, a filesystem, take a snapshot, and see how it differs from the LVM workflow.

Last ticket in the queue, and it is the calm one: a low-priority research task. Procurement is weighing storage options for the next refresh, and dbadmin1 wants a real proof of concept for Stratis, the managed pool-and-filesystem layer Red Hat pitches as a more modern take than LVM plus XFS. Build a pool on the spare partition /dev/sdb3, put a filesystem on it at /srv/stratis_test, snapshot it, prove the snapshot survives after you wreck the source, and write up how it differs from the LVM workflow. The production dbvg/dblv from earlier in the queue stays untouched.

Stratis is opinionated where LVM handed you the wheel, and two differences carry the ticket. The filesystem is always XFS, created and grown for you, so there is no mkfs and no lvextend plus xfs_growfs dance. And it is daemon-driven, which means the fstab mount has to wait for stratisd or the boot fails outright.

The ticket

lsblk
sudo lvs; sudo vgs    # confirm /dev/sdb3 is not used by LVM

Concept review. Stratis versus LVM.

man stratis

The mental model maps cleanly onto LVM. A Stratis pool is like a volume group. A Stratis filesystem is like a logical volume, except it is XFS, thin-provisioned, and grown automatically, so there is no separate mkfs and no lvextend plus xfs_growfs dance. Adding a disk is stratis pool add-data instead of vgextend, and snapshots are stratis filesystem snapshot instead of lvcreate -s. The big difference is that Stratis runs a daemon, stratisd, rather than being kernel-only like LVM.

pool                 like a volume group
filesystem           like a logical volume, but auto XFS and thin
stratis pool add-data    like vgextend
stratis filesystem snapshot   like lvcreate -s
resize               automatic, because it is thin-provisioned

Build a pool and a filesystem

Install the daemon and CLI, wipe any old signatures off the spare partition, then create the pool and a filesystem in it. Stratis filesystems appear under /dev/stratis/POOL/FS.

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

sudo wipefs -a /dev/sdb3          # removes old signatures, destroys data on it
sudo stratis pool create poc_pool /dev/sdb3
sudo stratis pool list

sudo stratis filesystem create poc_pool data
sudo mkdir -p /srv/stratis_test
sudo mount /dev/stratis/poc_pool/data /srv/stratis_test
df -h /srv/stratis_test

Persist it, and the flag that matters

The fstab entry uses the UUID and the filesystem type xfs, not stratis. The critical option is x-systemd.requires=stratisd.service, which tells systemd to wait for the daemon before mounting. Without it, boot tries to mount a device that does not exist yet and fails.

UUID=$(sudo blkid -s UUID -o value /dev/stratis/poc_pool/data)
echo "UUID=$UUID /srv/stratis_test xfs defaults,x-systemd.requires=stratisd.service 0 0" | sudo tee -a /etc/fstab

sudo umount /srv/stratis_test
sudo mount -a
mount | grep stratis_test

Snapshot and prove isolation

Write some data, snapshot the filesystem, mount the snapshot read-only, then change the source and confirm the snapshot still holds the original.

echo "important DB schema" | sudo tee /srv/stratis_test/schema.sql

sudo stratis filesystem snapshot poc_pool data data_snap_v1
sudo stratis filesystem list    # data and data_snap_v1 both appear

sudo mkdir -p /srv/stratis_snap
sudo mount -o ro,nouuid /dev/stratis/poc_pool/data_snap_v1 /srv/stratis_snap
cat /srv/stratis_snap/schema.sql

# change the live source
echo "DROP TABLE users;" | sudo tee /srv/stratis_test/schema.sql
cat /srv/stratis_snap/schema.sql    # snapshot still has the original

Cleanup

Since this is a proof of concept, tear it down so the spare partition is free again.

sudo umount /srv/stratis_snap /srv/stratis_test
sudo stratis filesystem destroy poc_pool data_snap_v1
sudo stratis filesystem destroy poc_pool data
sudo stratis pool destroy poc_pool
sudo sed -i '/stratis_test/d' /etc/fstab
lsblk /dev/sdb3

Exam questions

Write the command first.

Q1. Install the Stratis tools and start the daemon so it persists across reboot.

Q2. Create a pool pool1 from /dev/sdc, then a filesystem share inside it.

Q3. Persistently mount a Stratis filesystem at /data, ensuring the system waits for stratisd.service first.

Answers.

# A1
sudo dnf install -y stratisd stratis-cli
sudo systemctl enable --now stratisd
# A2
sudo wipefs -a /dev/sdc
sudo stratis pool create pool1 /dev/sdc
sudo stratis filesystem create pool1 share
# A3
UUID=$(sudo blkid -s UUID -o value /dev/stratis/pool1/share)
echo "UUID=$UUID /data xfs defaults,x-systemd.requires=stratisd.service 0 0" | sudo tee -a /etc/fstab
sudo mount -a

Final checklist: confirm everything works

If every check passes, the ticket, and the queue, is done.

# 1. stratisd installed, running, enabled
systemctl is-active stratisd

# 2. pool and filesystem created, mounted at /srv/stratis_test
sudo stratis filesystem list

# 3. snapshot taken and proven independent of the source
# 4. fstab used x-systemd.requires=stratisd.service
# 5. all three exam questions written from scratch
# 6. tracker entry checked off

Reply to dbadmin1: Stratis proof of concept done on /dev/sdb3. Pool, filesystem, and snapshot all work, and snapshots are instant and isolated. It is friendlier than LVM for snapshot-heavy work, but the daemon dependency means fstab needs x-systemd.requires=stratisd.service. Recommendation: keep LVM for the production DB, evaluate Stratis for dev environments.