User:Muaddeeb/Templates/openZFS

openZFS is an umbrella project aimed at bringing together individuals and companies using ZFS and working on its improvements, as well as making ZFS more widely used and developed in a true open-source manner.

OpenZFS brings together developers from the illumos, Linux, FreeBSD and OS X platforms, and a wide range of companies. High-level goals are:
 * to raise awareness of the quality, utility, and availability of open source implementations of ZFS
 * to encourage open communication about ongoing efforts to improve open source ZFS
 * to ensure consistent reliability, functionality, and performance of all distributions of ZFS.

Founding members of OpenZFS include Matt Ahrens, one of the main architects of ZFS.

Overview
illumOS, which derived from OpenSolaris, provides upstream source code for other ZFS implementations. While there are various differences between the illumos ZFS codebase and other open source implementations of ZFS, OpenZFS is strategically reducing existing platform-related differences in order to ease sharing of code.

For now the illumOS implementation of ZFS is the only reference fully native to the kernel residing in userland, and is also the de facto upstream of all the other implementations, but a better way to collaborate than today's ad hoc processes should always be welcome.

AFAIK, unification is in progress (?) to integrate the ZFS implementations into a platform-independent central repository with minimal platform code differences. Preliminary efforts will necessarily include: splitting ZPL into platform-independent and platform-specific parts; and moving illumos/Solaris-specific code out of the main files, and probably establishing OpenZFS as an official and separate sub-project (spin-off) under the umbrella of the illumos Foundation (as the nonprofit organization (NPO) to hold the assets of OpenZFS) where upstream collaboration can happen between developers of the different implementations.


 * Here are the links referring to this effort:

Matt Ahrens' suggestion

OpenZFS Developer Summit & Hackathon - Matt Ahrens

OpenZFS Developer Summit - November 18-19, 2013

OpenZFS Developer Summit | deirdre's notes

OpenZFS code repository

Reduce code differences - OpenZFS

OpenZFS platform-independent central repository

History
ZFS was originally developed by Sun Microsystems for the Solaris operating system. The source code for ZFS was released under the Common Development and Distribution License (CDDL) as part of the OpenSolaris operating system, and was subsequently ported to other platforms.

The following is a list of key events to the development of ZFS and its various implementations, leading to the creation of OpenZFS as an umbrella project:


 * 2001: Closed-source development of ZFS started with two engineers at Sun Microsystems.
 * 2005: Source code was released as part of OpenSolaris.
 * 2006: Development of a FUSE port for Linux started.
 * 2007: Apple started porting ZFS to Mac OS X.
 * 2008: A port to FreeBSD was released as part of FreeBSD 7.0.
 * 2008: Development of a native Linux port started.
 * 2009: Apple's ZFS project closed. The MacZFS project continued to develop the code.
 * 2010: OpenSolaris was discontinued. Further development of ZFS on Solaris was no longer open source.
 * 2010: illumos was forked from OpenSolaris as its open-source successor, and continued to develop ZFS in the open.  Ports of ZFS to other platforms continued pulling in upstream changes from illumos.
 * 2012: Feature flags were introduced to replace legacy on-disk version numbers, enabling easier distributed evolution of the ZFS on-disk format to support new features.
 * 2013: Alongside the stable version of MacZFS, ZFS-OSX used ZFS on Linux as a basis for the next generation of MacZFS.
 * 2013: The first stable release of a native Linux port.
 * 2013: Official announcement of the OpenZFS as an umbrella project.  New OpenZFS features and fixes are regularly pulled in from illumos and pushed into all ports to other platforms, and vice versa.

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 format and features available. 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 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 was to introduce feature flags, as a new versioning system which tags on-disk format changes with unique names. The system supports both completely independent format changes, as well as format changes that depend on each other. A pool can be moved and used between OpenZFS implementations as long as all of the feature flags in use by the pool are supported by both implementations.

Pool version used in OpenZFS for designating feature flags is 1000, what is an unchanging number that is expected to never conflict with version numbers given by Oracle. Legacy version numbers still exist for pool versions 1–28, and are implied by the version 1000. Future on-disk format changes are enabled/disabled independently via feature flags.

Feature flags are exposed as pool properties, following the naming scheme:
 * format of the property name is
 * is the reverse DNS name of the organization which developed the feature (for guaranteed unique names)
 * property names can be shortened to  if this is unambiguous.

For example,  is a valid property name, and it could be shortened to.

Pool features can have one of three states:
 * disabled – this feature will not be used, no on-disk format changes will be made (backwards compatible)
 * enabled – this feature will be used, no on-disk format changes have been made yet, but the software may make them at any time (still backwards compatible)
 * active – this feature has made backwards incompatible on-disk format changes to the pool.

Enabling any features automatically upgrades the pool legacy version to 1000 and automatically enables any other features they depend on. By default new pools are created with all supported features enabled. State of a feature can mostly be changed from active back toenabled, undoing the on-disk format changes and making the pool compatible again with an older OpenZFS implementation (some features may not be able to do this).

On-disk format changes can have one of two forms:
 * features for write – must be supported by an OpenZFS implementation in order to write to the pool, but the feature does not need to be supported to open the pool in read-only mode
 * features for read – must be supported in order to read from the pool, and there is no way to open a pool without reading from it.

For example,  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 read the pool. Writing to a pool with unsupported features inactive state is not possible.