1. Copy-on-Write (COW) Mechanism
Both the file systems use copy-on-write mechanism. This means that, if you are trying to modify a file, neither of the file systems will try to overwrite the existing data on the disk with the newer data. Instead, the newer data is written elsewhere and once the write operation is complete, the file system simply points to the newer data blocks and the old blocks get recycled over time. This mechanism allows both the file systems to have features like snapshots and cloning.
COW also prevents edge cases like partial writes,which can happen due to kernel panic or power failure and potentially corrupt your entire entire file system. With COW in place, a write has either happened or not happened, there’s no in between.
2. Pooling and RAID
Both the file systems intend on eliminating the need of a volume manager, raid and other abstractions that sit between the file system and the disks. This is more robust and reliable than having a hardware RAID controller, simply because it eliminates a single point of failure — The RAID controller itself.
OpenZFS offers a stable, reliable and user-friendly RAID mechanism. You can mirror between drives, use RAIDZ1 which spreads your data across 3 or more disk with one parity block. So it can withstand upton 1 disk’s failure per Vdev. Similarly, RAIDZ2 can use 4 or more disks and withstand upto 2 disks failing and similarly we have RAIDZ3.
Btrfs too has these features implemented, the difference is simply that it calls them RAID, instead of RAIDZ and so on. Some more complicated RAID array setups like RAID56 are buggy and not fit for use, at the time of this writing.
One of the reasons OpenZFS came so late on the GNU/Linux ecosystem is because of its license incompatibility with GNU GPL. Without getting into too much details, Btrfs is under GPL which allows users to take source code and modify it, but the modifications should also be published under GPL and stay open source.
OpenZFS on the other hand, is licensed under CDDL which is much more permissive and allows users to modify and distribute code with a greater degree of freedom.
4. Communities and Companies Behind Them
OpenZFS has a massive community behind it. FreeBSD community, Illumos community and many other open source projects rely on OpenZFS and thus contribute back to the file system. It has grown several fold in terms of code base, user base, features and flexibility ever since its inception. Companies like Delphix, iXsystems, Joyent and many more rely on it and have their developers work on because it is a core component of their business. Many more organizations might be using OpenZFS without our knowledge, thanks to the CDDL license, they don’t have to come forth and say out-right that they use it.
Btrfs had Red Hat as one of the main steward of its community. However, that recieved a major blow a while back when Red Hat deprecated the filesystem this means you won’t be seeing it in any future RHEL and the company won’t provide commercial support for it out-of-the-box. SUSE, however, has gone so far as to make it their default and their is still a thriving community behind the file system with contributions from Facebook, Intel and other 800 pound gorillas of the Silicon Valley.
ZFS was designed to be reliable right from the beginning. People have zpools dating back to the early 2000s that are still usable and guaranteed to not return erroneous data silently. Yes, there has been a few snafus with files disappearing on for OpenZFS on Linux but given its long history the track record has been surprising clean.
Btrfs, on the other hand, has had issues right from the beginning. With buggy interfaces to straight up data loss and file corruption. Even now, it is bit of a laughing stock in the community. Make of that what you will.
6. Supported OSes
Btrfs has had its origin has a file system for Linux while ZFS was conceived inside Sun, for Solaris OS. However, OpenZFS has long since been ported to FreeBSD, Apple’s OS X, open source derivatives of Solaris. It’s support for Linux came a little later than one would have predicted, but it is here and corporations rely on it. A project for making it run on Microsoft Windows is also making quite a bit of progress, although it is not quite there yet.
Conclusion: A Note on Monocultures
All of this talk may convince you to use OpenZFS to keep your data safe, and that is not a bad course of action. It is objectively better than Btrfs in terms of features, reliability, community and much more. However, in the long run this might not be good for the open source community, in general.
In a post titled similar to this one, the author talks about the dangerous of monocultures. I encourage you to go through this post. The gist of it is this — Options are important. One of the greatest strength of Open Source software (and software, in general)is that we have multiple options to adopt. There’s Apache and then there’s Nginx, there are BSDs and Linux, there is OpenSSL and there is LibreSSL.
If there is a fatal flaw in any of these key technologies, the world will not stop spinning. But with the prevalence of OpenZFS, the storage technology has turned into something of a monoculture. So, I would very much like for the developers and system programmers who are reading this, to adopt not OpenZFS but projects like Btrfs and HAMMER.