Our Senior Analyst’s take on this week’s Btrfs news from Red Hat
I don’t know who said it first but hats off to them: “The only thing worse than competition is no competition.” This adage applies equally to market making where no competition can mean no customers, and to monopolies and monocultures. Beyond the balance of freedom and control that Open Source provides, the sheer choice found in the Open Source ecosystem is one of its greatest strengths. Name any category of software from complete operating systems on up and you have a plethora of choices with drastically-different philosophies, licenses, countries of origin, programming languages, and user experiences. I personally have invested my volunteer time and career in Open Source hypervisors and file systems and I am saddened to hear that a fledgling alternative to OpenZFS suffered a setback this week with Red Hat’s announcement that it is deprecating Btrfs as a “Preview” file system. SUSE continues to support Btrfs in only RAID 10 equivalent configurations, and only time will tell if bcachefs proves to be a compelling alternative to OpenZFS. This vote of no confidence from Red Hat leaves OpenZFS as the only proven Open Source data-validating enterprise file system and with that role comes great responsibility.
“In their FACES, right?” Wrong. Monocultures risk becoming vulnerable monopolies which is why virus writers target Microsoft Windows and we may face an “Impending Crypto Monoculture“. My colleagues with the OpenBSD project are flattered by the popularity of OpenSSH but insist that they don’t want it to be the only game in town. Monoculturalism has long been a driving factor in computing and is often self-perpetuating: Why not use and standardize on a good technology? OpenSSH was the right solution at the right time and remains the de facto remote login tool on Internet-connected systems, open source and proprietary. The same is becoming true of OpenZFS, the community branch of Sun Microsystems’ revolutionary, and eventually open sourced enterprise file system.
Fortunately, like OpenSSH, OpenZFS really is as good as people say it is. OpenZFS goes to unrivaled lengths to protect your data and is highly flexible and scalable. I have addressed the merits of OpenZFS at length in various ways and I welcome you, in fact urge you to verify those merits on your own. I invite you to start that journey with a simple question: “Can you verify without a doubt that your data has not suffered from bit rot?” I look forward to your answer. In the meantime, I personally am confident that OpenZFS truly addresses the shortcomings of other file systems and does so in a way that is extremely accessible to me:
- OpenZFS has been my primary store under macOS for over five years and root file system under FreeBSD
- I have moved OpenZFS-formatted multi-terabyte USB drives from my FreeNAS system to a Raspberry Pi 3 running FreeBSD and run my backup routine without issue
- I have helped clients configure, maintain and optimize OpenZFS-based systems ranging from one to 500 terabytes in size
- I have watched the OpenZFS community grow to include amazing volunteers and vendors who do what was impossible with storage at any price only a few years ago
It is an honor to work with the OpenZFS community and iXsystems in particular who, thanks to FreeNAS, TrueNAS and TrueOS, has put OpenZFS in more hands than any other project or product on Earth. Both are just now accelerating from a trot to a gallop and I am very glad that they have been cautious and calculating. Drama is not something you want to associate with file systems or the hardware they run on. Thanks to Illumos, FreeBSD and FreeNAS, no one is stopping you from building a petabyte of storage with whatever hardware you can afford. You really want to get the right hardware but no artificial barriers stand in your way. As you can imagine, iXsystems is an excellent source of the right hardware for OpenZFS, but that too is something I invite you to verify on your own. I am after all, a geek, not a salesperson.
If it’s so good, why isn’t OpenZFS as popular on GNU/Linux?
Short answer: The OpenZFS and Linux kernel licenses are incompatible, but for a reason. It took time, but I accept Bryan Cantrill’s assertion that the Sun CDDL was essential to keeping Sun and later Oracle from doing evil things with ZFS. This pains me because I am not a believer in software patents and believe that permissively-licensed software is the way forward, even if paradoxically at times. I also believe in the 6 reasons for GPL lovers, haters, exploiters, and others to enjoy and support GPL enforcement because all free software licenses need to be enforced to remain meaningful. In the case of GNU/Linux, OpenZFS’ CDDL license is incompatible with the Linux kernel’s General Public License according to the Free Software Foundation and Software Freedom Conservancy. This is presumably why OpenZFS is not even a “Preview” file system in Red Hat Enterprise Linux as Btrfs was. To comply with each license, the end user must manually build OpenZFS for Linux and for what it’s worth, this sounds like a great way to stay true to GNU/Linux’s DIY community roots. Embrace the license diversity and obligations, or agree with me that the permissive licensing of each project would resolve this incompatibility without consequences.
To that point, I welcome the bcachefs project to consider a permissive license to allow its incorporation into FreeBSD, OpenBSD, NetBSD, macOS and even Windows to allow its merits to shine on equal footing and in the hands of as many users as possible. Until that happens though, the Illumos distributions, FreeBSD, TrueOS and FreeNAS remain the only tier-one OpenZFS operating systems and thus places you want to keep your valuable data for the foreseeable future.
June 2019 Update
It’s been nearly two years since I wrote this and some key developments are unfolding in service of the article’s key premise: File system diversity is a good thing. Let’s review these developments by file system:
bachefs author Kent Overstreet declared this month that, “It’s done cooking; let’s get this sucker merged”, and requests that this new contender file system be included in the Linux kernel. Hopefully this news is stimulating the formation of a larger a developer community that can help round out bcachefs’ features, test infrastructure, support utilities, and documentation. bcachefs joins Btrfs as a GPL-licensed copy-on-write file system option in Linux.
Just last week, Mark Harmstone released version 1.3 of WinBtrfs, the Btrfs port for Windows and in March, the “’multiple serious data-loss bugs” related to distributed parity RAID were downgraded to, “The parity RAID code has a specific issue with regard to data integrity … and … should not be used for metadata.” I sincerely hope the RAID 5/6 status wiki page is up to date as I have no desire to bad mouth Btrfs. From what I can tell, SUSE still does not suggest using Btrfs parity RAID in production with SUSE Linux.
On May 31st, the NetBSD Project released NetBSD 8.1 with OpenZFS as a supported file system. Like the 8.0 release before it, NetBSD has imported OpenZFS from FreeBSD, resulting in a vast improvement over the v13 ZFS that was shipped in earlier versions of NetBSD. Developer Jörgen Lundman has been steadily shipping releases of OpenZFS for macOS and is actively porting OpenZFS to Microsoft Windows. The macOS port continues to treat me very well, while the Windows port is still in its relative infancy. I have helped Jörgen test “ZFSin” on its first hardware machines and am actively exercising it in my lab. Once stable, OpenZFS on Windows should make FreeNAS an even better backup solution for Windows thanks to replication at the file system-level.
By my count, that’s three Open Source copy-on-write file systems for GNU/Linux, two for Windows, and six operating systems with OpenZFS support. With all this parallel development however can come project fragmentation. The OpenZFS community has long faced this risk thanks to its diverse operating system support, especially with the recent inclusion of Windows. Rest assured, the OpenZFS project leadership recognizes that project fragmentation is ultimately a disservice to the user and developer community. As a key step in unifying the OpenZFS code base, iXsystems is upstreaming native FreeBSD support into the ZoL code base to make the ZoL code base truly platform-agnostic and enable FreeNAS 12 to deliver the latest OpenZFS features. This is all great progress in the name of file system diversity and the arena is really heating up. My vote remains for OpenZFS but I will be bringing bcachefs and Btrfs into my lab to see how they perform.
Finally, a mystery: I have installed Ubuntu 19.04 and see no mention of OpenZFS as a supported file system out of the box. Neither the zpool nor zfs commands are present, nor the OpenZFS kernel module, despite a popular narrative that OpenZFS is coming to Ubuntu. There is no question that OpenZFS can be installed on Ubuntu, but it would appear that Canonical’s official OpenZFS support is narrowing to their “Metal As A Service” (MAAS) offering, possibly to address the licensing concerns raised above.
Michael Dexter, Senior Analyst