A few years ago, there was one thing I always remember hearing–“Btrfs is not ready”. This was always confusing to me since the decision for utilizing Btrfs as a file system caused the two largest Linux-based enterprise companies to take polar opposite stances. Instead of allowing the file system as an option, Red Hat chose to completely remove it from Red Hat Enterprise Linux 8, their latest enterprise release. On the other hand, SUSE made a completely different decision–make it the default file system in all of their distributions. Huh?
It certainly confused me at the time, but I have to admit, I had very little interest in file systems back then. I didn’t run large production machines or anything like that, so ext4 (and for a brief time, ext3) has served me well for my personal machines. Of course, I’m an extremely paranoid user who backs up their data frequently to multiple locations, especially if something large hits, like a new kernel patch.
Even so, I’ve long heard the virtues sung of Sun Microsystem‘s (now Oracle) Zetibyte File System, or ZFS (you might know it as “Zed FS” ;)). Developed for Sun’s UNIX operating system, Solaris (and later their OpenSolaris platfom), ZFS was hailed as the “next generation” file system–and in many aspects that it true. The BSDs jumped on ZFS after OpenSolaris was ended and Solaris was closed sourced by Oracle and many BSD users have been enjoying its benefits for many years already.
But, Linux? Nope. Unfortunately the CDDL license that ships with ZFS is considered incompatible with Linux’s GPL v2 by many, including the man with the say, Linus Torvalds. So, in 2007 a new project was started to try to bring a next generation file system to Linux. That file system was named b-tree file system, or Btrfs for short (b-tree is a complex data structure that the file system was created around).
Though many problems were encountered with Btrfs in the early stages of the project, it has since found use in a variety of high profile companies including SUSE and Facebook. The improvements to Btrfs from engineers at these companies have brought Red Hat back to taking a serious look at the updated file system.
In turn, with input from their large contributor base, the Fedora steering council offered a vote on the subject of bringing Btrfs into the next iteration, Fedora 33, as the default file system, similar to how openSUSE has operated for years now. And, it appears that the vote passed quite significantly.
This is a huge turn of events for Btrfs. Though the file system has enjoyed extensive work from SUSE and Facebook engineers, throwing the might of Fedora and Red Hat engineers behind the project will only improve it drastically. As we know, Fedora serves as a testing grounds for Red Hat Enterprise Linux, so if the transition to Btrfs proves to be a net win for Fedora, it is likely that it will also become the default file system in the next iteration of RHEL, version 9.
Also, with the 19.10 release of Ubuntu, the developers added an option for experimental ZFS support for the hugely popular Linux distribution. Though Canonical is known for marching to the beat of their own drum, if Red Hat and SUSE begin backing Btrfs, along with the questionable issues around ZFS licensing, we may see Canonical adopt Btrfs as well instead of ZFS. This is not too farfetched, as Canonical has done this more than once–dropping Unity8 in favor of GNOME 3, dropping Upstart in favor of systemd, and dropping the Mir display server in favor of Wayland.
If this were to happen in the future, it is easy to say that the future of Btrfs is looking brighter than it ever has. There is no doubt that the next generation file system has grown considerably over the last few years and many now consider it to be in a stable and reliable state. Offering many advantages of ZFS without the licensing issue will definitely make Btrfs an enticing option for more Linux distributions to adopt as the default file system, or at least a choice upon installation.
It will be interesting to see how this all plays out, but I for one am extremely happy to see Btrfs received the praise that it certainly deserves today. I want to congratulate the Btrfs developers for sticking with the file system and putting in a ton of work into make it a true competitor against other, similar file systems for Linux. Best of luck to the Btrfs developers and the Fedora team as this experiment continues to unfold. I know one thing is for certain–I will definitely be trying this out as soon as Fedora 33 drops. After spending some significant time with it on openSUSE, I really think this is a great direction and provides the possibility of another united front for developers to place their trust. Only time will tell!
If you would like to read the official proposal from Fedora, which has now passed, you can find it here. If you would like to check out Btrfs, you can find the official documentation for it here and the Wikipedia entry for it here. In addition, if you would like to try out Btrfs for yourself, it is recommended to use one of the openSUSE distributions, where it ships by default. The openSUSE downloads can be found here.
I’ll definitely be watching how successfully they pull this off. If it works with nobody’s data getting lost, then they will have a rather large advantage over many other distros, who will be apparently shown up as being too conservative (in just playing it ultra-safe with ext4, but then having no features like filesystem snapshotting, etc).
As long as the install is to a non-USB, non-RAID-5-or-6 attached drive, then I expect there will be no data loss. But if Fedora doesn’t discriminate against USB-attached drives getting installed to (and there is now a possibility of a flaky USB controller, cough cough Realtek, introducing errors, which will appear to be Fedora’s fault), then they might bring a bad name upon themselves.
Dear Fedora, I suggest refusing to install using BTRFS, if a USB controller is between the installer, and the target installation media. Just don’t. Install BTRFS only to “internal” disks, meaning SATA-attached, M.2 attached, etc. Not USB-attached. Protect your reputation.
Join the discussion at forum.tuxdigital.com