The Storage Headache That Made Me Rethink Everything
Six months ago, one of my production VPS instances threw a disk-full error at 3 AM. Not unusual — except the root filesystem was sitting at 94% while another partition I had set aside for backups was barely touched at 12%.
Traditional LVM could technically solve this, but after managing 10+ Linux VPS instances over three years, I’ve learned the hard way that resize operations under pressure are where mistakes happen. That incident pushed me to seriously evaluate Stratis Storage, which I had been ignoring since it landed in RHEL 8.
Six months later, I have a clearer picture of where Stratis earns its keep and where it falls short. The reality is more complicated than the official documentation lets on.
Why Traditional Storage Management Falls Short
Root cause of my 3 AM problem wasn’t disk shortage — it was partition rigidity. Specifically:
- Static partitions carved out during server provisioning, months before actual usage patterns were clear
- LVM logical volumes that could be extended, but required manual intervention and carried resize risks on live filesystems
- No built-in compression — I was paying for storage I could have been getting for free
- Snapshot support existed in LVM but was clunky to manage and easy to misconfigure
Fundamentally, traditional Linux storage tools were designed for an era when disk layout was determined upfront and rarely changed. Modern workloads — containers, databases, logs that grow unpredictably — don’t fit that model anymore.
ZFS solves most of this brilliantly, but licensing keeps it out of the default kernel tree on RHEL/CentOS/AlmaLinux systems. Btrfs is in-kernel and increasingly capable, but still carries a reputation for instability under heavy write loads — the RAID 5/6 issues are real, well-documented, and not fully resolved as of kernel 6.x. That’s the gap Stratis is trying to fill.
What Stratis Actually Is (and Isn’t)
Stratis isn’t a new filesystem. It’s a local storage management layer sitting on top of existing technology: device-mapper thin provisioning handles pool expansion, XFS handles the actual filesystem, and stratisd is the daemon orchestrating everything through D-Bus.
Building on XFS means Stratis inherits decades of filesystem maturity while adding features XFS alone can’t provide:
- Thin provisioning: Filesystems report more space than physically exists, expanding on demand as the pool grows
- Snapshots: Copy-on-write snapshots without pre-allocating space
- Storage pooling: Multiple block devices appear as a single pool
- Optional encryption: Clevis/Tang integration for network-bound disk encryption
Worth being upfront about the gaps: native data compression is not in Stratis 3.x. It’s on the roadmap but hasn’t shipped. Same goes for deduplication and anything beyond basic redundancy for RAID. If compression is your primary driver right now, ZFS or Btrfs are the honest answers.
Comparing Your Options: Stratis vs. LVM vs. ZFS vs. Btrfs
LVM + XFS/ext4
Still the most mature option available. Resize operations are manual, there’s no native snapshot at the filesystem layer, but it’s rock-solid and supported everywhere. Best for setups where maximum control and minimum abstraction matter more than convenience.
ZFS on Linux (OpenZFS)
Feature-complete with compression, dedup, RAID-Z, and excellent snapshot tooling. Memory requirements add up fast — ARC cache alone can consume 1–4 GB on a busy pool, which stings on smaller VPS instances. The zfs-dkms package works well on Ubuntu/Debian but introduces kernel update friction on RHEL-family systems. Licensing is a non-issue for personal or open-source use; it matters if your org has legal constraints around CDDL.
Btrfs
In-kernel, feature-rich, and increasingly stable for single-disk and RAID 1 setups. Desktop use? No complaints. Production servers handling sustained high write throughput — say, a busy PostgreSQL instance or a container host with hundreds of image layers — I’d still want a careful burn-in period before committing.
Stratis
Best fit for RHEL/AlmaLinux/Fedora environments where you want modern storage features without the ZFS licensing debate. CLI commands are noticeably simpler than their LVM equivalents, and thin provisioning addresses the partition-sizing-upfront problem directly. Not the right choice if compression is non-negotiable today.
Setting Up Stratis: A Working Example
Below is the exact setup I use on a fresh AlmaLinux 9 server. Before touching any production system, I ran this sequence on a local VM — a habit that’s saved me from more than one embarrassing mistake.
Installation
# Install stratisd daemon and CLI tool
sudo dnf install stratisd stratis-cli -y
# Enable and start the daemon
sudo systemctl enable --now stratisd
# Verify it's running
sudo systemctl status stratisdCreating a Storage Pool
Adding two block devices to a single pool is the core of the thin-provisioning model. In this example, /dev/sdb and /dev/sdc are each 20 GB, giving a 40 GB physical pool:
# List available block devices first
lsblk
# Create a pool named 'datapool' with two devices
sudo stratis pool create datapool /dev/sdb /dev/sdc
# Verify pool creation
sudo stratis pool listExpected output:
Name Total Physical Properties UUID
datapool 40 GiB / 592 MiB in use ~Ca,~Cr,~Op a1b2c3d4-...The ~Ca,~Cr,~Op flags mean cache, encryption, and overprovisioning are all off — sensible defaults for a first setup.
Creating Filesystems
Thin provisioning gets interesting here. A filesystem can report 1 TiB to the OS even though the physical pool is only 40 GB. It sounds alarming until you understand that XFS won’t actually consume that space — it grows only as data is written:
# Create a filesystem within the pool
sudo stratis filesystem create datapool appdata
# List filesystems
sudo stratis filesystem list
# Mount it
sudo mkdir /mnt/appdata
sudo mount /dev/stratis/datapool/appdata /mnt/appdata
# Check reported size (will show 1TiB — this is expected)
df -h /mnt/appdataFor persistence across reboots, add it to /etc/fstab:
# Get the UUID
sudo blkid /dev/stratis/datapool/appdata
# Add to /etc/fstab
UUID=<your-uuid> /mnt/appdata xfs defaults,x-systemd.requires=stratisd.service 0 0Don’t skip the x-systemd.requires=stratisd.service option. It tells systemd to start stratisd before attempting this mount. Miss it, and you’ll spend 20 minutes debugging a boot failure like I did on my first deployment.
Adding Capacity to a Pool
This is the feature that would have saved my 3 AM. When a pool runs low, adding a new disk is one command — no unmounting, no resizing, no sweating:
# Add a new block device to an existing pool
sudo stratis pool add-data datapool /dev/sdd
# Pool automatically grows — no filesystem resize needed
sudo stratis pool listFilesystems in the pool see the additional space immediately. In practice, I’ve added a 20 GB disk to a live pool with active writes — the operation completed in under two seconds and application logs showed zero interruption.
Snapshots
# Create a snapshot before a risky operation
sudo stratis filesystem snapshot datapool appdata appdata-snap-20260819
# List all filesystems including snapshots
sudo stratis filesystem list datapool
# Mount the snapshot to verify data
sudo mkdir /mnt/snap
sudo mount /dev/stratis/datapool/appdata-snap-20260819 /mnt/snap
# Rollback: unmount live fs, snapshot becomes the new origin
# (requires destroying and recreating — no single rollback command exists yet)Six Months In: An Honest Assessment
Thin provisioning and pool expansion work exactly as advertised. Three separate servers, three capacity additions mid-operation, zero minutes of downtime — that alone justifies adoption for my use case.
Rough edges exist, though, and they’re worth knowing upfront. Snapshot rollback is immature compared to ZFS — where zfs rollback is a single command, Stratis requires destroying and recreating the filesystem from a snapshot. Pool usage monitoring is manual unless you build your own alerting around stratis pool list output; there’s no built-in threshold notification in stratisd 3.x. And compression remains unshipped — if that was a decision driver, Stratis isn’t ready yet.
For RHEL-family servers running containerized workloads or databases with unpredictable growth patterns, Stratis lands in a useful middle ground. Management overhead compared to raw LVM is substantially lower, commands are human-readable, and thin provisioning directly solves the partition-sizing problem that bit me at 3 AM.
Start with a non-critical server. Run it for a month. Check the stratisd logs, watch pool usage, do a snapshot and recovery drill. Storage changes always deserve validation in your specific environment before you stake critical data on them — Stratis is no exception to that rule, regardless of how approachable the CLI feels.
