FAQ

Who contributes to OpenZFS?
OpenZFS brings together developers from multiple open-source forks of the original ZFS project from OpenSolaris to help ensure the compatibility and quality of all of our implementations.

Why are there four different repositories?
Each repository supports a different operating system. Even though the core of OpenZFS is platform-independent, there are a significant number of platform-specific changes need to be maintained for the parts of ZFS which interact with the rest of the operating system (VFS, memory management, disk i/o, etc.).

Are new features and improvements shared between the different repositories?
Yes. Each implementation regularly ports platform-independent changes from the other implementations. One of the goals of OpenZFS is to simplify this porting process.

Are there plans to merge the different repositories?
Not exactly. We want to simplify the sharing of code between implementations by having a platform-independent central repository that runs as a userland process on any operating system. Developers from any implementation could then easily install and test platform-independent changes in that central repository. Every implementation would port changes from this central repository instead of searching the commit history of the other implementations.

There are several reasons we do not want a single repository to support all operating systems:
 * Every developer would have the burden of testing changes for four different operating systems. Most developers are only familiar with kernel development on their operating system of choice, so this would be a huge hurdle to development.
 * Each implementation has its own process for integrating changes, some of which cannot be changed. For example OpenZFS on illumos must follow the illumos integration process because it is part of the larger illumos operating system repository. Most developers are only familiar with the integration process for their operating system of choice. Learning other processes and interacting with multiple communities would be a hurdle to development.

Are storage pools created by OpenZFS portable between operating systems?
Pools can be moved freely between different implementations of OpenZFS wherever the implementations support the same feature flags.

You can disable a feature flag for a pool when the pool is created. This may be appropriate if you expect to use the pool with a different implementation that does not support the feature.

To maintain compatibility, new feature flags are usually ported to all operating systems very quickly.

Just one pool version is associated with feature flags: version 5000. Versions less than 5000 can not use feature flags.

Are storage pools created by OpenZFS compatible with ZEVO and with Oracle® Solaris?
Yes, if you specify a pool version at the time of creation of the pool:


 * 28 or less.

GreenBytes ZEVO Community Edition 1.1.1 is based on ZFS pool version 28 and ZFS file system (zpl) version 5. Its use of a standard ZFS on-disk format is therefore binary compatible with ZFS on other platforms that support version 28 or greater.

Whilst ZEVO CE 1.1.1 was not intended to support direct interchange with other platforms, there are reports of success.

Are pools created by Solaris compatible with OpenZFS?
Yes, if created with pool version 28 or earlier.

Oracle's closed source uses of pool versions 29–35 are not compatible.

Can disks that use ZFS be used with Microsoft® Windows®?
An OpenZFS port of code to Windows is not likely in the foreseeable future. The OpenZFS launch discussion on Slashdot touches upon some of the issues.

In Stack Exchange, Access a ZFS volume in Windows? includes approaches to using the disks with alternative operating systems, and accessing that data from Windows.

Do you plan to release OpenZFS under a license other than the CDDL?
No. We do not have the power to change the license of OpenZFS. No single entity holds the copyright to all of the OpenZFS code and all contributors to OpenZFS maintain copyright to their changes. Changing the license would require the consent of each one whose changes are part of the current codebase. That is basically everyone who has contributed since 2001.

What is the conflict between CDDL and GPLv2 licenses?
The CDDL and GPLv2 conflict when you distribute a binary compiled in part from code under the CDDL and in part from code under the GPL where the GPLv2 part is considered to be a derived work of GPLv2 code. This stems from section 2b of the GPLv2. Essentially:
 * Any binary that is in whole or in part derived from GPLv2 code must in whole be under the GPLv2
 * Both the CDDL (section 3.4) and the GPLv2 (section 6) disallow the imposition of additional restrictions.

Does the conflict prevent a merge of ZFS into the Linux source tree?
No. This would be considered an aggregate redistribution of source code, which is not restricted by either license. The official GPL FAQ explicitly states that the redistribution of aggregates is okay.

Does the conflict prevent redistribution of binary ZFS kernel code for Linux?
Discussions of ports to Linux of proprietary software as loadable kernel modules established that ports of code from other operating systems to Linux are not derived works of Linux.

It is:
 * fine to build and redistribute binary ZFS kernel modules (i.e. CONFIG_ZFS=m)
 * unacceptable to redistribute any Linux kernel binary that contain ZFS code (i.e. CONFIG_ZFS=y) – the Linux kernel binary is a derived work of Linux and must be distributed in whole under the terms of the GPLv2 as per section section 2b of the GPL.

The ZFSOnLinux project also maintains its own FAQ entry on this.