Red Hat deprecates BTRFS, is Stratis the new ZFS-like hope?

For years, almost since its inception in 2009, Btrfs has been looked up to be the successor to the popular EXT4 filesystem. A brave project born to be on-par with ZFS, Btrfs has caught over the years the interest of many people among administrators and users alike, but its life has been more troubled than you might imagine.Btrfs was originally created in 2008 to be a Linux alternative to ZFS since the latter couldn’t be included due to licensing issues; although Canonical is still trying, and even included it Ubuntu 16.04. Btrfs was only accepted in the kernel mainline only in 2009. For much of its life, BTRFS has been considered unstable; the original wiki has a status page to update users about stability. Although unstable, BTRFS had many interesting features/promises (thanks to Wikipedia):

• Mostly self-healing in some configurations due to the nature of copy-on-write
• Online defragmentation and an autodefrag mount option
• Online volume growth and shrinking
• Online block device addition and removal
• Online balancing
• Offline filesystem check
• Online data scrubbing for finding errors and automatically fixing them for files with redundant copies
• RAID 0, RAID 1, and RAID 10
• Subvolumes (one or more separately mountable filesystem roots within each disk partition)
• Transparent compression (zlib and LZO), configurable per file or volume
• Snapshots of subvolumes
• Checksums on data and metadata (CRC-32C)
• Block discard (reclaims space on some virtualized setups and improves wear leveling on SSDs with TRIM)
• Send/receive (saving diffs between snapshots to a binary stream)
• Incremental backup
• Out-of-band data deduplication (requires userspace tools)

During the past 4 years, BTRFS has been moving fast and many distributions included it in installation options. The major adopter remains SUSE with SLES 12 using it as default filesystem. In 2016 the BTRFS RAID5/6, a feature that was never fully stable, was found to be plagued with bugs that made it unsafe and exposed users to data-loss. Still to date the RAID5/6 wiki page states:

The parity RAID code has multiple serious data-loss bugs in it. It should not be used for anything other than testing purposes.

Also Google has recently shown attention for the project and one of its engineers has confirmed they’re exploring the use of Btrfs on Android.

BTRFS and Red Hat

Red Hat introduced BTRFS as a technology preview in RHEL 6 and has been over the years one of the major contributors. Excluding a brief deprecation, or rather a bad-wording in RHEL 6.8 documentation, Red Hat has always shown interest in BTRFS and before August 2017 everyone would’ve bet Red Hat would’ve continued development. With an unexpected move, Red Hat states in the RHEL 7.4 documentation:

Btrfs has been deprecated

The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux.

The Btrfs file system did receive numerous updates from the upstream in Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise Linux 7 series. However, this is the last planned update to this feature.

Stratis vs BTRFS/ZFS

Just like the other two competitors, the newly born Stratis aims to fill the gap on Linux, but there’s much difference. Aside from the brave decision to use the Rust programming language, Stratis aims to provide Btrfs/Zfs-esque features using an incremental approach. Rather than rebuilding the entire stack Stratis aims to extend existing projects to provide the user with a unique point of interaction with the user. Currently, the most appealing projects to be extended are: DM, XFS and LVM (much debated). Although Stratis is much younger than its competitors, this feature aims for Fedora 28, which is only one year from now. If you want to know more about Stratis here’s an excerpt from the GitHub repo:

Stratis (which includes stratisd as well as stratis-cli), provides ZFS/Btrfs-style features by integrating layers of existing technology: Linux’s devicemapper subsystem, and the XFS filesystem. stratisd manages collections of block devices, and exports a D-Bus API. Stratis-cli’s stratis provides a command-line tool which itself uses the D-Bus API to communicate with stratisd.

SUSE and BTRFS

If Brazil, one of the world biggest producers of beef, would announce to stop producing fish: would you wonder, whether Peru, one of the world biggest producers of fish, would stop producing fish?

You probably wouldn’t.

If one of the rather small contributors to the btrfs filesystem announced to not support btrfs for production systems: should you wonder, whether SUSE, strongest contributor to btrfs today, would stop investing into btrfs?

You probably shouldn’t.

SUSE is committed to btrfs as the default filesystem for SUSE Linux Enterprise, and beyond.

In the meantime SUSE, the current #1 upstream contributor, reaffirms its love for Btrfs stating that Red Hat quitting isn’t a problem for the project. SUSE will continue to support Btrfs for the foreseeable future and explains many other companies like Oracle, Facebook and Fujitsu are still working actively on the project. The post then explains how Btrfs was used to create efficient images for the Raspberry Pi and how IoT may benefit from Btrfs features such as compression, encryption and quotas (albeit not all the three are ready).

• Author
• Recent Posts

mark

The IT guy with a slight look of boredom in his eyes. Freelancer. Current interests: Kubernetes, Tensorflow, shiny new things.

Latest posts by mark (see all)

• 2020 A year in review for Marksei.com - 30 December 2020
• Red Hat pulls the kill switch on CentOS - 16 December 2020
• OpenZFS 2.0 released: unified ZFS for Linux and BSD - 9 December 2020