# OpenZFS

OpenZFS is an open-source implementation of the ZFS file system and volume manager initially developed by Sun Microsystems for the Solaris operating system, and is now maintained by the OpenZFS Project. Similar to the original ZFS, the implementation supports features like data compression, data deduplication, copy-on-write clones, snapshots, RAID-Z, and virtual devices that can create filesystems that span multiple disks.
One of the main capabilities of OpenZFS is self-healing. The file system can detect and correct errors while in use, without the need for a dedicated file system checker. This feature makes it suitable for mission-critical applications that require high availability.
OpenZFS is mainly used in enterprise and data center environments, as well as consumer devices like network-attached storage (NAS) devices, where data reliability and safety is essential. While initially designed for Solaris, development has since focused on Linux, while ports exist for various BSD distributions and macOS. Unlike Oracle ZFS, OpenZFS is licensed under the Common Development and Distribution License (CDDL), enabling both open-source and commercial use of the file system.
Founding members of OpenZFS include Matt Ahrens, one of the main architects of ZFS. In 2020, the codebases of OpenZFS and ZFS on Linux, a kernel module allowing ZFS to be used on Linux, were merged and released as OpenZFS 2.0, allowing other non-Linux operating systems to receive the various improvements that the Linux driver had incorporated over time.

## History

The ZFS file system was originally developed by Sun Microsystems for the Solaris operating system. The ZFS source code was released in 2005 under the Common Development and Distribution License as part of the OpenSolaris operating system, and it was later ported to other operating systems and environments.
The following is a list of key events in the development of ZFS and its various implementations:
* 2001: Closed-source development of ZFS began with two engineers at Sun.
* 2005: ZFS source code was released as part of the OpenSolaris project.
* 2006: Development of a ZFS port to FUSE for Linux started.
* 2007: Apple began a project to port ZFS to Mac OS X.
* 2008: A port to FreeBSD was released as part of FreeBSD 7.0.
* 2008: Development of a native ZFS Linux port started, known as ZFS on Linux.
* 2009: Apple's ZFS project closed, and the MacZFS project took over development of the driver. (It has since also been discontinued; it was current through Mac OS X 10.9).
* 2010: OpenSolaris was discontinued following the acquisition of Sun Microsystems by Oracle, resulting in the further development of ZFS on Solaris being no longer open-source.
* 2010: Following the discontinuation, a project named illumos was formed and forked OpenSolaris to continue open-source development, ZFS included. Ports of ZFS to other platforms continued by pulling in upstream changes from illumos.
* 2012: Feature flags were introduced to replace legacy on-disk version numbers, enabling easier development of the ZFS on-disk format to support new features.
* 2013: Coexisting with the stable version of MacZFS, its prototype generation (known as OpenZFS on OS X or O3X) uses ZFS on Linux as the new upstream codebase.
* 2013: The first stable release of ZFS on Linux.
* 2013: Official announcement of the OpenZFS Project as an organization for maintaining OpenZFS. New features and fixes are regularly pulled into OpenZFS from illumos and pushed into all ports to other platforms, and vice versa.
* 2016: Ubuntu 16.04 includes the open-source ZFS file system variant by default.
* 2020: ZFS on Linux was merged into OpenZFS and added FreeBSD support, unifying the codebase for both platforms.

### Ports

As the FSF (Free Software Foundation) claimed that there was a legal incompatibility between the CDDL and the GPL in 2005, Sun's implementation of the ZFS file system couldn't be used as a basis for the development of a module in the Linux kernel, couldn't be merged into the mainline Linux kernel, and Linux distributions generally did not include it as a precompiled kernel module. As a workaround, FUSE, a framework that allows file systems to run in userspace, was used on Linux as a separation layer for which the licensing issues did not apply, although with a set of its own issues that includes a performance penalty. However, the April 2016 release of Ubuntu 16.04 LTS includes ZFS as a kernel module.

### Apple and OS X

In the release version of Mac OS X 10.5, ZFS was available in read-only mode from the command line, which lacks the possibility to create z-pools or write to them. Before the 10.5 release, Apple released the "ZFS Beta Seed v1.1", which allowed read-write access and the creation of z-pools; however, the installer for the "ZFS Beta Seed v1.1" has been reported to only work on version 10.5.0, and has not been updated for version 10.5.1 and above. In August 2007, Apple opened a ZFS project on their Mac OS Forge web site. On that site, Apple provided the source code and binaries of their port of ZFS which includes read-write access, but without an installer. In October 2009, Apple discontinued development of the ZFS project on Mac OS Forge with no explanation. Apple removed everything but the CDDL-licensed portion of the source code for their final build of the ZFS project, code named "10a286". Complete ZFS support was originally advertised as a feature of Snow Leopard Server before launch, but by the time the operating system was released all references to this feature had been removed from its features page.
Apple's "10a286" source code release, and versions of the previously released source and binaries, have been preserved and new development had been adopted by the MacZFS project to continue development outside of Apple. As of July 2012, Mac ZFS implements z-pool version 8 and ZFS version 2, released with the October 2008 release of Solaris. Additional historical information and commentary can be found on the Mac ZFS web site and FAQ. However, the project ceased development in mid 2013 with a message asking users to switch to O3X.

## Implementations
### OpenSolaris

* OpenSolaris 2008.05, 2008.11 and 2009.06 use ZFS as their default filesystem.

#### OpenIndiana

* OpenIndiana uses OpenZFS with feature flags as implemented in Illumos. ZFS version 28 used up to version 151a3.
* By upgrading from OpenSolaris snv_134 to both OpenIndiana and Solaris 11 Express, one also has the ability to upgrade and separately boot Solaris 11 Express on the same ZFS pool.

### macOS

* Open ZFS on OSX (abbreviated to O3X) is an implementation of ZFS for macOS. O3X is under active development, with close relation to ZFS on Linux and illumos' ZFS implementation, while maintaining feature flag compatibility with ZFS on Linux. O3X implements z-pool version 5000, and includes the Solaris Porting Layer (SPL) originally written for Mac ZFS, which has been further enhanced to include a memory management layer based on the illumos kmem and vmem allocators. O3X is fully featured, supporting LZ4 compression, deduplication, ARC, L2ARC, and SLOG.
* MacZFS is free software providing support for ZFS on macOS. The stable legacy branch provides up to ZFS pool version 8 and ZFS filesystem version 2. The development branch, based on ZFS on Linux and OpenZFS, provides updated ZFS functionality, such as up to ZFS zpool version 5000 and feature flags. This implementation is no longer supported, and developers have advised users to switch to O3X.
* A proprietary implementation of ZFS (Zevo) was available at no cost from GreenBytes, Inc., implementing up to ZFS file system version 5 and ZFS pool version 28. Zevo offered a limited ZFS feature set, pending further commercial development; it was sold to Oracle in 2014, with unknown future plans.

### BSD
#### DragonFlyBSD

* Edward O'Callaghan started the initial port of ZFS to DragonFlyBSD.

#### NetBSD

* The NetBSD ZFS port was started as a part of the 2007 Google Summer of Code and in August 2009, the code was merged into NetBSD's source tree.

#### FreeBSD

* Paweł Jakub Dawidek ported ZFS to FreeBSD, and it has been part of FreeBSD since version 7.0. This includes zfsboot, which allows booting FreeBSD directly from a ZFS dataset.
* FreeBSD's ZFS implementation is fully functional; the only missing features are kernel CIFS server and iSCSI, but the latter can be added using externally available packages. Samba can be used to provide a userspace CIFS server.
* FreeBSD 13.0-RELEASE switches ZFS implementation from illumos-based code base to the unified OpenZFS 2 code base. This change allows FreeBSD to receive OpenZFS improvements much quicker.

#### MidnightBSD

* MidnightBSD, a desktop operating system derived from FreeBSD, supports ZFS storage pool version 6 as of 0.3-RELEASE. This was derived from code included in FreeBSD 7.0-RELEASE. An update to storage pool 28 is in progress in 0.4-CURRENT and based on 9-STABLE sources around FreeBSD 9.1-RELEASE code.

#### TrueOS (formerly PC-BSD)

* TrueOS (formerly known as PC-BSD, now defunct) was a desktop-oriented distribution of FreeBSD, which inherited its ZFS support.

#### TrueNAS Core, (formerly FreeNAS)

* TrueNAS Core, an embedded open source network-attached storage (NAS) distribution based on FreeBSD, has the same ZFS support as FreeBSD and PC-BSD.

#### pfSense

* pfSense, an open source BSD based router, supports ZFS, including installation and booting to ZFS pools, as of version 2.4.

#### OPNsense

* OPNsense, an open source FreeBSD based firewall and router distribution, supports ZFS, including installation and booting.

#### XigmaNAS

* XigmaNAS (formerly NAS4Free), an embedded open source network-attached storage (NAS) distribution based on FreeBSD, has the same ZFS support as FreeBSD, ZFS storage pool version 5000. This project is a continuation of FreeNAS 7 series project.

#### Debian GNU/kFreeBSD

* Being based on the FreeBSD kernel, Debian GNU/kFreeBSD has ZFS support from the kernel. However, additional userland tools are required, while it is possible to have ZFS as root or /boot file system in which case required GRUB configuration is performed by the Debian installer since the Wheezy release.
* As of January 31, 2013, the ZPool version available is 14 for the Squeeze release, and 28 for the Wheezy-9 release.

### Linux

Although the ZFS filesystem supports Linux-based operating systems, difficulties arise for Linux distribution maintainers wishing to provide native support for ZFS in their products due to legal incompatibilities between the ZFS's CDDL license and the GPL license used by the Linux kernel. To enable ZFS support within Linux, a loadable kernel module containing the CDDL-licensed ZFS code must be compiled and loaded into the kernel. According to the Free Software Foundation, the wording of the GPL license legally prohibits redistribution of the resulting product as a derivative work, though this viewpoint has caused some controversy.

#### ZFS on FUSE

One potential workaround to licensing incompatibility was trialed in 2006, with an experimental port of the ZFS code to Linux's FUSE system. The filesystem ran entirely in userspace instead of being integrated into the Linux kernel, and was therefore not considered a derivative work of the kernel. This approach was functional, but suffered from significant performance penalties when compared with integrating the filesystem as a native kernel module running in kernel space. As of 2016, the ZFS on FUSE project appears to be defunct, as the ZFS on Linux kernel driver has prevailed over the userspace one.

#### Native ZFS on Linux

A native port of ZFS for Linux produced by the Lawrence Livermore National Laboratory (LLNL) was released in March 2013, following these key events:
* 2008: prototype to determine viability
* 2009: initial ZVOL and Lustre support
* 2010: development moved to GitHub
* 2011: POSIX layer added
* 2011: community of early adopters
* 2012: production usage of ZFS
* 2013: stable GA release
As of August 2014, ZFS on Linux uses the OpenZFS pool version number 5000, which indicates that the features it supports are defined via feature flags. This pool version is an unchanging number that is expected to never conflict with version numbers given by Oracle.

#### KQ InfoTech

Another native port for Linux was developed by KQ InfoTech in 2010. This port used the zvol implementation from the Lawrence Livermore National Laboratory as a starting point. A release supporting zpool v28 was announced in January 2011. In April 2011, KQ Infotech was acquired by sTec, Inc., and their work on ZFS ceased. Source code of this port can be found on GitHub.
The work of KQ InfoTech was ultimately integrated into the LLNL's native port of ZFS for Linux.

#### Source code distribution

While license incompatibilities may arise with the distribution of compiled binaries containing ZFS code, it is generally agreed that distribution of the source code itself is not affected by this. In Gentoo Linux, configuring a ZFS root filesystem is well documented and the required packages can be installed from its package repository. Slackware also provides documentation on supporting ZFS, both as a kernel module and built into the kernel.

#### Ubuntu integration

The question of the CDDL license's compatibility with the GPL license resurfaced in 2015, when the Linux distribution Ubuntu announced that it intended to make precompiled OpenZFS binary kernel modules available to end-users directly from the distribution's official package repositories. In 2016, Ubuntu announced that a legal review resulted in the conclusion that providing support for ZFS via a binary kernel module was not in violation of the provisions of the GPL license. Other organizations such as the Software Freedom Law Center followed Ubuntu's conclusion, while the FSF and SFC reiterated their opposing views.
Ubuntu 16.04 LTS ("Xenial Xerus"), released on April 21, 2016, allows the user to install the OpenZFS binary packages directly from the Ubuntu software repositories. As of 2024, no legal challenge has been brought against Canonical regarding the distribution of these packages.
As of 2019, Ubuntu supports experimental installation of ZFS as a root filesystem, starting with the 19.10 release ("Eoan Ermine"), to support coexistence of a nearly pure ZFS OS with GRUB and other operating systems on the same disk.

#### TrueNAS Scale

A version of TrueNAS by iXsystems, based on Debian Linux. As with TrueNAS Core (based on FreeBSD), it uses OpenZFS for storage and adds a variety of additional features. These include expanded device driver support, KVM virtual machines, PCIe passthrough and container support via Kubernetes and Docker. Furthermore, it allows clustered Docker and ZFS via gluster. Information about the current release can be found at the iXsystems Software Status page.

### Microsoft Windows

A port of open source ZFS was attempted in 2010 but after a hiatus of over one year development ceased in 2012. In October 2017, a new port of OpenZFS was announced by Jörgen Lundman at OpenZFS Developer Summit.
A newer open source port of ZFS which is considered a BETA release, can be found also on GitHub.

## Version history

Legend: :
* Latest FOSS stable release
| ZFS Pool Version Number | Release date | Significant changes |
| 5000 | OpenZFS | Unchanging pool version to signify that the pool indicates new features after pool version 28 using ZFS feature flags rather than by incrementing the pool version |

### Pool versions and feature flags

Originally, version numbers of the pool and file system were incremented as new features were introduced, in order to designate the on-disk file system format and available features. This worked well when a single entity controlled the development of ZFS, and this versioning scheme is still in use with the ZFS in Oracle Solaris.
In a more distributed development model, having a single version number is far from ideal as all implementations of OpenZFS would need to agree on all changes to the on-disk file system format. The solution selected by OpenZFS was to introduce feature flags as a new versioning system that tags on-disk format changes with unique names, and supports both completely independent format changes and format changes that depend on each other. A pool can be moved and used between OpenZFS implementations as long as all feature flags in use by the pool are supported by both implementations.$^{:20,26–27}$$^{:2–3}$
In OpenZFS, the pool version is permanently set to 5000, signifying that the pool indicates new features by setting or unsetting ZFS feature flags rather than by incrementing the pool version. The number 5000 was chosen because it is expected to never conflict with version numbers given by Oracle. Legacy version numbers still exist for pool versions 1–28. Future on-disk format changes are enabled / disabled independently via these feature flags.
Legacy version numbers still exist for pool versions 1–28, and are implied by the pool version 5000; the initial proposal was to use 1000 as the pool version.$^{:4}$ Future on-disk format changes are enabled and disabled independently via feature flags.
Feature flags are exposed as pool properties, following these naming scheme rules:$^{:4}$
* Format of the property name is feature@<org-name>:<feature-name>
* <org-name> is the reverse DNS name of the organization that developed the feature, ensuring unique property names.
* Property names can be shortened to feature@<feature-name> when they remain unambiguous.
For example, feature@com.foocompany:async_destroy is a valid property name, and it could be shortened to feature@async_destroy.$^{:4}$
Each pool feature can be in either disabled, enabled, or active state. Disabled features are those that will not be used, and no on-disk format changes will be made; as a result, such features are backward-compatible. Enabled features are those that will be used, no on-disk format changes have been made yet, but the software may make the changes at any time; such features are still backward-compatible. Active features are those that have made backward-incompatible on-disk format changes to the pool.$^{:5}$
When any pool feature is enabled, legacy version of the pool is automatically upgraded to 5000 and any other prerequisite features are also enabled. By default, new pools are created with all supported features enabled. In general, state of a feature can be changed from active back to enabled, undoing that way performed on-disk format changes and making the pool compatible again with an older OpenZFS implementation; however, for some features that might not be possible.$^{:5,9}$
On-disk format changes can be associated with either features for write or features for read. The former are the features that an OpenZFS implementation must support to be capable of writing to the pool, while supporting such features is not mandatory for opening the pool in read-only mode. The latter are the features that an OpenZFS implementation must support to be able to read from the pool or to just open it, because opening a pool is not possible without actually reading from it.$^{:7}$
For example, async_destroy feature adds a new on-disk data structure to keep track of freed datasets, but an OpenZFS implementation does not need to know about this data structure to access the pool in read-only mode. Additionally, writing to a pool that has some features in active state is not possible by an OpenZFS implementation that does not support the same features.$^{:7–8}$
A list of feature flags and which operating systems support them is available from the OpenZFS documentation Web site (here the old Open-ZFS.org Web site)

#### OpenZFS 2.0

Historically, OpenZFS has been implemented as a core ZFS code, with each operating system's team adapting it to fit into their projects. This led in some cases to feature stagnation and divergence of features and command lines, as different operating systems developed divergent features and bug fixes, often for a single platform rather than across all platforms. Over time, new feature development shifted from Illumos to Linux. These new features and fixes then had to be backported to Illumos before they could be re-ported for FreeBSD. But this was difficult because the Linux version also included many smaller changes, which were hard to disentangle.
In 2018, it was agreed that OpenZFS development would be overhauled to remedy these issues. Rather than try to import all the Linux changes to other platforms piecemeal, the entire Linux ZFS code would be 'pivoted' as a whole, with other platforms being based on the more actively developed Linux version. A wide range of ported and new features, including many long-desired enhancements, would also be rolled out or ported across platforms, and future changes would be discussed across platforms before being implemented. The plans included appropriate porting layers to prevent Linux, GPL or Linux-KPI shim code from being introduced to other platform kernels.
The features in progress or ported for OpenZFS 2.0 is lengthy, and includes:
* Faster rollout of enhancements and new features across platforms
* Command line standardisation
* Improved pool portability (ZFS pools created on one system can be equally used by another)
* Wider cross-platform feature parity and platform independence
* Overlay (union) mounts accepted by default
* Bug fixes and enhancements
* ZTS and various other features working on FreeBSD
* TRIM and ACLMODE enhancements
* ZFS holds (from FreeBSD)
* Enhanced native NFSv4 ACLs (FreeBSD)
* Enhanced AES-GCM performance for encrypted pools
* Redacted send/receive
* Log spacemap and other metaslab management enhancements - a project to re-implement ZFS' management of free space and "metaslabs" for much greater efficiency
* Fast clone deletion
* Zstd data compression as a new option
* Channel program property inheritance
* AltiVec RAID-Z
* Bookmark support and copying
* Direct IO support
* Persistent L2ARC (L2ARC retained across reboots)
* Sequential (high speed) scrub and resilver
* Scrub pause/resume
* Resilver restart
* Device (VDEV) removal
* Zpool initialize and checkpoint
* Channel programs
* Large Dnode
* Allocation classes (allowing specific high speed storage to be designated for metadata and deduplication tables)
* Parallel pool mounting
* Per-vdev properties
* Deduplication enhancements – dedup-log (high speed deduplication), dedup table size limits, and deduplication table preloading (loaded fully at one time rather than piecemeal as needed), listed as "nice to have" in 2018, were all stated in April 2020 to be "coming along nicely" or largely complete