- 1 General
- 2 Development Model
- 3 Compatibility
- 4 Licensing
- 5 Configuration
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.
|ZFS on Linux||Webpage||GitHub|
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.).
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 and only used on older versions of Oracle Solaris.
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 about the Linux port?
The ZFS on Linux project maintains its own FAQ entry on this.