Red Hat Killed Btrfs, Then Built Something Weirder
Red Hat pulled Btrfs out of RHEL 8 entirely and replaced it with Stratis, a userspace daemon that bolts XFS onto LVM thin provisioning and device mapper. Btrfs was never a supported filesystem on RHEL to begin with: it shipped as a Technology Preview in RHEL 6 and 7, got deprecated in 7.4, and was removed outright in 8. Fedora, the same company’s upstream playground, has shipped Btrfs as the desktop default since Fedora 33. That is not a typo. One team at the same company ships Btrfs to millions of desktops and tells its enterprise customers to use something else entirely on servers.
So: if you run RHEL, Rocky, Alma, or CentOS Stream and you want snapshots, thin provisioning, and simple pool management without learning a new filesystem’s failure modes, use Stratis. If you want copy-on-write with checksummed data by default and you can tolerate a filesystem still finding its footing on RHEL-family distros, use Btrfs. If you already know LVM and XFS cold and you don’t need snapshots or thin pools, skip both and keep doing what you’re doing. Stratis is not a Btrfs clone. It is a management layer over tools you already trust, and that distinction decides who should use it.
What Stratis Actually Is (Hint: Not a Filesystem)
Btrfs is one filesystem that owns the whole stack: allocation, checksums, snapshots, and optional RAID all live inside a single copy-on-write tree. Stratis is a coordinator. stratisd runs as a background service, talks to the kernel over D-Bus, and wires together device mapper thin pools with a plain XFS filesystem sitting on top. When you create a Stratis pool, you get a thin pool built from your block devices. When you create a filesystem inside that pool, you get an XFS filesystem carved out of thin storage.
# Create a Stratis pool from one or more block devicesstratis pool create datapool /dev/sdb
# Carve an XFS-backed filesystem out of the poolstratis filesystem create datapool projectfs
# Mount it like any other filesystemmount /stratis/datapool/projectfs /mnt/projectCompare that to Btrfs, where the filesystem and the volume manager are the same binary:
mkfs.btrfs -L datapool /dev/sdbmount /dev/sdb /mnt/projectFewer moving parts, sure. But Btrfs’s single tree is also where every one of its historical bug reports lives: quota groups, balance operations, and RAID5/6 all touch the same code path that also owns your data. Stratis spreads the same job across XFS (mature, boring, does one thing) and device mapper (also mature, also boring). Splitting the job across two settled components instead of one newer one is the whole design philosophy.
The RAID Question, Answered Straight
This is the part people get wrong constantly: Stratis does not implement its own RAID. It has no parity engine, no mirroring code, nothing. Stratis pools accept block devices, and if you want redundancy, you build it before Stratis ever sees the disk, using mdadm or a hardware RAID controller. Stratis then treats the resulting array as one device.
# Build the redundancy yourself with mdadm firstmdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
# Now hand Stratis a single, already-redundant block devicestratis pool create datapool /dev/md0Stratis 3.3.0 added stratis pool extend-data, which lets a pool pick up extra capacity when the RAID array underneath it grows, which only makes sense if Stratis already assumes RAID lives one layer down. Native RAID inside Stratis was proposed as a dm-raid-backed feature years back, and there is no evidence it has shipped as a default, supported capability as of stratisd 3.9.3. The Stratis team has said publicly that RAID is one of the features driving its on-disk metadata rework, so this is planned work rather than a closed door.
Btrfs, by contrast, does its own RAID: RAID0, RAID1, RAID10, and the multi-copy raid1c3/raid1c4 profiles are native and considered production-ready. RAID5 and RAID6 are also native, and they are still something you should avoid running. btrfs-progs warns you on creation, the manual page calls the implementation deficient, and that warning has stood for years with no fix in 2026. The honest comparison, then: Stratis defers to mdraid, which is boring and works, while Btrfs’s own RAID5/6 code is still the thing every wiki and mailing list tells you to steer clear of. Handing redundancy to mdraid is not Stratis cutting a corner. Mdraid has been shipping since the late 1990s and it does one job well, so Stratis stacking on top of it saves you from a home-grown parity implementation that still hasn’t earned production trust after ten years of warnings.
Encryption: Keyring, Clevis, and What Btrfs Skips Entirely
Stratis supports pool-level encryption bound to a kernel keyring key, and it can also bind an encrypted pool to a Tang server for network bound disk encryption, so a pool unlocks automatically only when it can reach your Tang server on the network.
# Bind an already-encrypted pool to a Tang server (NBDE)stratis pool bind nbde datapool pool1key http://tang.internal.example \ --thumbprint l3fZGUCmnvKQF_OA6VZF9jf8z2sStratis 3.9.0 (April 2026) added online encryption, decryption, and reencryption, so you can flip encryption on or rotate the underlying key without unmounting anything.
Btrfs has none of this. The filesystem itself has no encryption feature at all. If you want an encrypted Btrfs volume, you put LUKS underneath the block device first, then run mkfs.btrfs on the decrypted mapping, same as you would with ext4 or XFS. That works fine, but it means Btrfs gets nothing like Tang integration or online rekeying without you scripting cryptsetup yourself.
cryptsetup luksFormat /dev/sdbcryptsetup open /dev/sdb encrypted_datamkfs.btrfs /dev/mapper/encrypted_dataSnapshots: Independent Filesystems vs a Shared Tree
Stratis snapshots are a distinct design choice worth understanding before you rely on them. A Stratis snapshot is a thinly provisioned, read-write point-in-time copy of a filesystem, and once it exists, it is not tied to its origin’s lifetime. Delete the source filesystem and the snapshot keeps working.
stratis filesystem snapshot datapool projectfs projectfs-backupBtrfs subvolume snapshots work differently. A snapshot shares extents with its source through copy-on-write, which makes the snapshot itself instant and nearly free on creation, but the snapshot and its origin live in the same subvolume tree and the relationship between them is something you track yourself (with tools like snapper or your own naming convention), not something the filesystem enforces as independence.
btrfs subvolume snapshot /mnt/project /mnt/project-backupNeither model is wrong. Stratis gives you a clean, independent filesystem you can mount, unmount, or destroy on its own. Btrfs gives you a cheaper, faster snapshot that assumes you’re managing a tree of related subvolumes on purpose. If your mental model is “snapshot equals full independent copy,” Stratis matches that model directly. If your mental model is “snapshot equals cheap rollback point,” Btrfs matches that one.
The Thin Provisioning Trap (And Why XFS Can’t Shrink)
Every Stratis filesystem lives on thin-provisioned storage by default, meaning the sum of your filesystems’ reported sizes can exceed the pool’s actual physical capacity. That is normal and useful, right up until the pool’s real space runs out. When an overprovisioned pool fills up, writes start failing and the underlying device mapper stack can land in a state that risks data loss, which is exactly the failure mode you signed up to avoid by using a managed storage tool in the first place.
Stratis gives you two ways to defend against this. First, stratis pool create --no-overprovision caps the sum of your filesystems’ logical sizes at the pool’s real physical capacity, trading flexibility for a hard guarantee you can’t outrun your disks. Second, even with overprovisioning enabled, stratisd raises an alert once the pool’s physical space is fully allocated, so you get a warning before things go sideways instead of finding out from a failed write at 2 AM.
There’s a second wrinkle here that has nothing to do with thin provisioning and everything to do with XFS: XFS filesystems can grow, but they cannot shrink. Stratis inherits this directly, since every Stratis filesystem is XFS underneath. Size a Stratis filesystem generously up front, because there is no xfs_shrink waiting for you later. If you provisioned too large and need the space back, your only real option is to create a new, smaller filesystem and copy the data over.
Data Integrity: The One Round Btrfs Wins Clean
Btrfs checksums both data and metadata by default, using CRC32C unless you pick xxhash, SHA-256, or BLAKE2 at creation time, and the kernel verifies every checksum on every read. Silent bit rot gets caught before it reaches your application, which is the single strongest argument for Btrfs on a home server holding photos or backups you can’t easily regenerate.
Stratis does not ship this as a default feature. Neither the RHEL documentation nor stratisd’s own release notes describe a shipped, on-by-default checksumming layer for Stratis pools. If you want dm-integrity style protection under a Stratis pool as of September 2026, you’re adding it yourself below the stack rather than getting it from stratis pool create out of the box. One detail that trips people up: stratis pool create does accept an --integrity flag, so it looks like the feature is there. It pre-allocates on-disk room for an integrity layer that has not shipped. It reserves space today, it does not checksum anything. For a home lab storing irreplaceable data, that gap matters more than the RAID story does. Stratis has named integrity alongside RAID as a feature its metadata rework is meant to support, so expect this to change, but do not plan storage around a feature that has not landed.
Stratis vs Btrfs vs LVM+XFS By Hand
| Stratis | Btrfs | LVM + XFS by hand | |
|---|---|---|---|
| Native RAID | No, use mdraid/hardware RAID underneath | Yes (RAID5/6 still not production-safe) | No, use mdraid/hardware RAID |
| Encryption | Keyring + Clevis/Tang NBDE, online rekey | None native, needs LUKS underneath | None native, needs LUKS underneath |
| Snapshots | Independent filesystem, not tied to origin | Shared-extent, tied to subvolume tree | LVM thin/CoW snapshots, manual management |
| Default checksums | Not shipped by default | Data + metadata, on by default | None |
| Filesystem shrink | No (XFS limitation) | Yes | No (XFS) / N/A (other fs) |
| RHEL support | Tech preview through RHEL 9.2, supported since 9.3 | Not supported on RHEL family | Fully supported everywhere |
| Learning curve | Low if you know LVM/XFS already | Moderate, new mental model | You already know it |
If you already run RHEL, Rocky, Alma, or CentOS Stream, Stratis is the path of least resistance for anyone who wants snapshots and thin pools without hand-rolling LVM thin volumes and XFS mounts every time. If you’re on Fedora, Debian, or Arch and you want checksummed data with native snapshots and don’t mind avoiding RAID5/6, Btrfs remains the better default. And if none of the extra features apply to you, plain LVM and XFS by hand is still the least surprising option there is, it’s like hiring a forklift to move a couch: technically Stratis and Btrfs both work for a single unencrypted, unsnapshotted volume, but your neighbors will have questions about why you didn’t just use mkfs.xfs.
The distro question matters more than most people give it credit for. Stratis is a RHEL-family tool through and through: it lands in Fedora first, then makes its way into RHEL, Rocky, Alma, and CentOS Stream on Red Hat’s own release cadence. Nothing stops you from building stratisd from source on Debian or Ubuntu, but you’d be running an unpackaged, unpatched daemon with none of the testing Red Hat puts behind it, and your 2 AM self will not thank you for that gamble on a box holding data you actually care about.
Common Questions
Can I use Stratis on Ubuntu or Debian?
No, not with any real support. Stratis ships as a packaged, supported tool in the RHEL family (RHEL, Rocky, Alma, CentOS Stream) and in Fedora. Debian and Ubuntu don’t carry stratisd or stratis-cli in their standard repositories, and building it yourself gets you an unsupported, unpatched setup with none of Red Hat’s testing behind it.
Does Stratis support RAID 5 or RAID 6?
Not directly. Stratis has no native RAID of any kind, including RAID5 or RAID6. You build that redundancy with mdadm or a hardware RAID controller first, then hand Stratis the resulting array as a single block device. This sidesteps Btrfs’s own RAID5/6 code, which is still marked unsafe for production in 2026.
Is Stratis fully supported on RHEL 9?
Yes, since RHEL 9.3. Stratis shipped as a Technology Preview from RHEL 8 through RHEL 9.2, and Red Hat’s 9.3 release notes drop it from the Technology Preview list. On RHEL 9.0 through 9.2, treat Stratis as preview quality and keep production storage off it.
Can I shrink a Stratis filesystem after creating it too large?
No. Stratis filesystems are XFS underneath, and XFS has no shrink operation at all, only grow. If you oversized a filesystem, your only path back is creating a new, smaller Stratis filesystem and copying your data over, then removing the old one. Plan sizes conservatively before you commit.
Does Stratis check data for corruption like Btrfs does?
Not by default. Btrfs checksums data and metadata automatically and verifies them on every read. Stratis’s documentation and release notes don’t describe a shipped, default checksumming layer for Stratis pools as of September 2026. If bit rot detection matters to you, you’d need to add that protection yourself beneath the Stratis stack, or pick Btrfs instead.
