Stratis or BTRFS?

By EricMesa

August 15, 2017 - 4 minutes read - 776 words

It’s been a while since btrfs was first introduced to me via a Fedora version that had it as the default filesystem. At the time, it was especially brittle when it came to power outages. I ended up losing a system to one such use case. But a few years ago, I started using btrfs on my home directory. And even developed a program to manage snapshots. My two favorite features of btrfs are that Copy on Write (COW) allows me to make snapshots that only take up space when the file that was snapshot changes and the ability to dynamically set up and grow RAID levels. I was able to use this recently to get my photo hard drive on RAID1 without having to have an extra hard drive (because most RAID solutions destroy what’s on the drive).

However, btrfs has been plagued with some important issues - for example RAID5/6 is unstable, not recommended, and after many years still hasn’t solved the write hole. (Something the very similar ZFS has had solved for years) Look online and you’ll find scores of tales of people who have suffered unrecoverable data loss from btrfs.

A few years ago Red Hat deprecated btrfs on RHEL6. That makes sense given the long support times of the RHEL releases. The team at Red Hat has to backport kernel fixes and that gets complicated as time goes by. btrfs has grown by leaps and bounds since RHEL6. But a couple days ago (when I write this - 10 days before the blog post is going to appear), Red Hat announced it was getting deprecated on RHEL7. There was lots of speculation on the net and someone who used to hack on btrfs for RHEL mentioned that since he left, no one at Red Hat worked on it. Suse is the distro that employes btrfs hackers at this point. Then, yesterday, Stratis was announced. From the Phoronix article I read about Stratis in:

First a quote from the announcement of Stratis:

Stratis is a new tool that meets the needs of Red Hat Enterprise Linux (RHEL) users calling for an easily configured, tightly integrated solution for storage that works within the existing Red Hat storage management stack. To achieve this, Stratis prioritizes a straightforward command-line experience, a rich API, and a fully automated, externally-opaque approach to storage management. It builds upon elements of the existing storage stack as much as possible, to enable delivery within 1-2 years. Specifically, Stratis initially plans to use device-mapper and the XFS filesystem. Extending or building on SSM 2.1.1 or LVM 2.1.2 was carefully considered. SSM did not meet the design requirements, but building upon LVM may be possible with some development effort.

From the Wikipage describing that it’s going to land in Fedora 28:

a local storage system akin to Btrfs, ZFS, and LVM. Its goal is to enable easier setup and management of disks and SSDs, as well as enabling the use of advanced storage features – such as thin provisioning, snapshots, integrity, and a cache tier – without requiring expert-level storage administration knowledge. Furthermore, Stratis includes monitoring and repair capabilities, and a programmatic API, for better integration with higher levels of system management software.

Then from the author of the Phoronix article:

For Stratis 1.0 they hope to support snapshot management, file-system maintenance, and more. With Stratis 2.0 is where they plan to deal with RAID, write-through caching, quotas, etc. With Stratis 3.0 is where it should get interesting as they hope for “rough ZFS feature parity” and support send/receive, integrity checking, RAID scrubbing, compression, encryption, deduplication, and more. Only in the first half of 2018 is when they expect to reach Stratis 1.0. No word on when they anticipate getting to Stratis 3.0 with ZFS feature parity.

Interesting. I led me on a path of exploration of LVM and other tech. First of all, I don’t imagine btrfs is going to sit still, unworked on, while this happens. Maybe it finally reaches its stability goals. Maybe the threat of Stratis attracts more hackers to btrfs. Or, maybe Stratis catches up with, and surpasses, btrfs. I think if they can make the dynamic RAID work, and can get stability up to ZFS levels, I could move over to Stratis. If not, I’m still thinking about LVM and XFS or ext4 for my home-built NAS rather than btrfs (or together with btrfs if it doesn’t get too complex for snapshotting purposes) because that would (potentially) let me grow directories indefinitely in a way that works as my backup needs grow. This will require more knowledge and planning, though. I’ll keep documenting my research here.