Latest / Linux Server Admin with Fexingo: Sysadmin, Bash, and Server Engineering / How to Use Linux Stratis for Storage Management
Transcript
- Lucas: If you've ever had to add a drive to a production Linux server and then had to resize filesystems or move data around, you know the pain of traditional volume management. Luna: Yeah, LVM is powerful, but it can feel like you're juggling physical volumes, volume groups, and logical volumes. It's a lot of layers. Lucas: Exactly. And if you're coming from something like ZFS, you might miss the simplicity of pool-based storage. But ZFS isn't in the mainline kernel, and the licensing can be a concern. So today I want to talk about Stratis — a storage management tool that Red Hat has been pushing for a few years now. Luna: Stratis. I've seen the name, but I haven't actually used it. What's the elevator pitch? Lucas: Think of Stratis as a storage volume manager that gives you zfs like features — pools, thin provisioning, snapshots, tiering — but built on top of existing kernel technologies like device mapper and XFS. It's designed to be simpler to configure and manage. Luna: Simpler how? Because LVM isn't exactly rocket science once you get used to it. Lucas: Sure, but with Stratis you don't manage individual physical volumes or logical volumes. You create a pool — a 'stratis pool' — which can consist of one or more block devices. Then you create filesystems from that pool. The pool handles all the allocation, thin provisioning, and snapshots. You don't need to pre-allocate space. Luna: So it's like a storage pool that you just pull from as needed. Sounds similar to what ZFS does. Lucas: Exactly the analogy. And like ZFS, Stratis supports snapshots for point-in-time recovery, and it can automatically tier data between faster and slower drives. But the big difference is that Stratis is part of the mainline Linux kernel since version 5.10, so it's fully in-tree and doesn't require DKMS or out-of-tree modules. Luna: That's a huge plus for enterprise servers where you want minimal kernel modifications. So how do you actually set it up? Let's say I have a fresh RHEL 9 server with two NVMe drives. Lucas: First, you install the stratisd daemon and the command-line tool. On RHEL 9 it's just 'dnf install stratisd stratis-cli'. Then enable and start the service: 'systemctl enable —now stratisd'. That's it for prerequisites. Luna: And then you create the pool? What's the command? Lucas: 'stratis pool create mypool /dev/nvme0n1 /dev/nvme1n1'. That creates a pool called 'mypool' using both NVMe drives. Stratis will automatically configure them in a raid like scheme — by default it uses a 'raid0' style for performance, but you can specify other levels. Luna: No manual pvcreate, vgcreate, lvcreate? That's refreshing. So after the pool is created, I can start making filesystems. Lucas: Yes. 'stratis filesystem create mypool datafs' creates a thin-provisioned filesystem. It's visible as /dev/stratis/mypool/datafs. You can format it with XFS — Stratis uses XFS by default — and mount it. The filesystem can grow up to the total pool size automatically. Luna: Thin provisioning out of the box. That's great for virtual machine storage where you might overcommit a bit. What about snapshots? Lucas: Snapshots are similarly straightforward. 'stratis filesystem snapshot mypool datafs datafs-snap' creates a snapshot of the datafs filesystem. It's instant and space-efficient — only the differences are stored. You can then roll back or mount the snapshot for recovery. Luna: Let's talk about a real scenario. Say I accidentally delete a critical config file and I need to roll back. Walk me through that with Stratis. Lucas: Okay. Let's simulate that. You have /mnt/data mounted from the Stratis filesystem. You delete /mnt/data/etc/nginx.conf. With a snapshot taken earlier, you can roll back the filesystem to that point. But here's the catch: Stratis doesn't have a 'rollback' command per se. You destroy the current filesystem and recreate it from the snapshot. Luna: So it's more like a clone than an instant revert. How does that work in practice? Lucas: First, unmount the filesystem. Then 'stratis filesystem destroy mypool datafs' to remove the corrupted one. Then 'stratis filesystem snapshot mypool datafs-snap datafs' — you create a new filesystem from the snapshot, naming it the original name. Remount it, and you're back to the state at snapshot time. Luna: That's not too bad. But you lose any changes made after the snapshot. In a production system you'd probably want to mount the snapshot alongside the original and copy back only the deleted file. Lucas: Exactly. You can mount the snapshot at another mount point and selectively restore. That's actually the safer approach. Stratis snapshots are read-write by default, so you can even modify them without affecting the original. Luna: That's a nice feature. Now, what about monitoring pool health? Can I see how much space is used or if a drive is failing? Lucas: Yes. 'stratis pool list' shows an overview of all pools. 'stratis pool list —name mypool' gives details like total physical size, total allocated, and the number of devices. For filesystem-level, 'stratis filesystem list' shows each filesystem's usage. And you can check the pool's health with 'stratis pool list —name mypool —output BlockDevs' to see individual device status. Luna: So it's all command-line based, no GUI needed. That's good for server environments. But how does Stratis handle drive failures? If one of the NVMe drives dies in a RAID0 pool, you lose data, right? Lucas: Yes, by default Stratis uses RAID0-like striping across devices. But you can create a pool with a 'raid1' redundancy mode. You specify that at creation: 'stratis pool create —raid-level raid1 mypool /dev/sda /dev/sdb'. That gives you mirroring. The trade-off is half the usable capacity. Luna: And if a drive fails in a raid1 pool, can you replace it? Lucas: You can. You'd remove the failed device with 'stratis pool remove-data mypool /dev/sda', add a new one with 'stratis pool add-data mypool /dev/sdc', and Stratis will resync the data. It's not as automatic as some SAN solutions, but it's manageable. Luna: One thing I've always wondered about Stratis: how does it compare to something like LVM with thin provisioning? Both can do snapshots, both can grow filesystems. Why would someone choose Stratis? Lucas: The main advantage is simplicity. With LVM, you need to understand physical volumes, volume groups, logical volumes, thin pools, and metadata. With Stratis, it's just pools and filesystems. The CLI is much more intuitive. Also, Stratis integrates with systemd for automatic mounting and has built-in performance monitoring via stratisd's D-Bus interface. Luna: But LVM is battle-tested and widely documented. Stratis is relatively new. Has it reached production maturity? Lucas: Red Hat has been pushing Stratis as a technology preview since RHEL 8. In RHEL 9, it's fully supported. I've been running it on a few non-critical servers for about a year, and it's been stable. But you're right — for mission-critical storage, LVM or a dedicated SAN is still the norm. Stratis is great for container hosts, VMs, or any scenario where you want flexible, thin-provisioned storage without the complexity. Luna: That makes sense. And there's also the open-source aspect — Stratis is licensed under the GPL, so no licensing headaches like with ZFS on some distributions. Lucas: Exactly. If you're on a Debian or Ubuntu server, you can install stratisd from the repositories too, and it works the same way. For anyone who manages multiple Linux servers, having a consistent storage tool across distributions is valuable. Luna: And you know, this is exactly the kind of practical tool talk that keeps this show ad-free. We don't run ads — no sponsor breaks, no product pitches. If you find these episodes useful and want to support that choice, you can find us at buy me a coffee dot com slash fexingo. No pressure, but it helps keep the server lights on. Lucas: Yeah, that's the spirit. Listener support is what keeps this going. Anyway, back to Stratis — one more feature I want to mention is tiering. You can add a fast SSD and a slower HDD to the same pool, and Stratis will automatically move frequently accessed data to the SSD. Luna: That's a form of automated caching. How do you set that up? Lucas: At pool creation, just include both types of devices. Stratis detects the speed characteristics and promotes hot data to faster storage. You can also manually specify a cache device with 'stratis pool add-cache mypool /dev/nvme2n1'. It's not as granular as a dedicated tiering solution, but for many workloads it's a zero-config performance boost. Luna: I can see this being useful for a database server where you have a mix of workloads. But what about encryption? Can Stratis work with LUKS? Lucas: Yes. You can create a LUKS container on a block device and then add that encrypted device to a Stratis pool. Stratis doesn't handle encryption itself, but you can layer it with LUKS or dm-crypt. Stratis also integrates with the kernel's keyring for unlocking encrypted devices at boot. Luna: So it's flexible. Let's talk about the future. Do you see Stratis replacing LVM eventually? Lucas: I don't think it'll replace LVM entirely, but it offers a simpler alternative for many use cases. Red Hat is actively developing it, and the community interest is growing. For new deployments where you don't need the full LVM feature set, Stratis is worth a look. Luna: What's the best way for listeners to get started? Any gotchas they should watch out for? Lucas: Start with a test VM. Install stratisd, create a pool with a couple of virtual disks, play with snapshots and tiering. One gotcha: if you remove a device from a pool, you need to ensure it's not the only copy of data — so in raid0, avoid removing devices. Also, the 'stratis' command must be run as root or with sudo. And if you want to use Stratis for the root filesystem, that's possible but more complex — I'd recommend keeping it for data or application storage. Luna: Good advice. So bottom line: Stratis gives you a zfs like experience with native Linux kernel support, easier management, and enough features for most server storage needs? Lucas: That's the pitch. It's not a silver bullet, but it's a solid tool to have in your sysadmin toolkit. And because it's in the kernel, you don't need to worry about third-party module compatibility. Luna: Alright, I'm going to spin up a VM tonight and give Stratis a try. Thanks Lucas. Lucas: Happy to share. Next week we'll talk about another tool that might simplify your life — see you then.