Difference between revisions of "Feature Flags"

Jump to navigation Jump to search
92 bytes added ,  17:09, 4 February 2017
Clarity (recent misunderstanding about version 28); Wayback Machine for a blog post that is no longer served by illumos; a FreeBSD manual page that is not version-specific
(Clarity (recent misunderstanding about version 28); Wayback Machine for a blog post that is no longer served by illumos; a FreeBSD manual page that is not version-specific)
Line 1: Line 1:
Originally the ZFS on-disk format was versioned with a single number that was increased whenever a new on-disk format change was introduced. This worked well when a single entity controlled the development of ZFS; however, in the more distributed development model of OpenZFS a single version number is not ideal. Every OpenZFS implementation would need to agree on every change to the on-disk format.
ZFS on-disk formats were originally versioned with a single number, which increased whenever the format changed. The numbered approach was suitable when development of ZFS was driven by Oracle alone.  


One of the first OpenZFS projects was a new versioning system called "feature flags" that 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's on-disk format is portable between OpenZFS implementations as long as all of the feature flags in use by the pool are supported by both implementations.
For distributed development of OpenZFS, version numbering was unsuitable. Any change to the number would have required agreement, across all implementations, of each change to the on-disk format.  


For more details see these [http://blog.delphix.com/csiden/files/2012/01/ZFS_Feature_Flags.pdf slides (Jan 2012)] and [http://illumos.org/man/5/zpool-features <tt>zpool-features(5)</tt>] (illumos) or [http://www.freebsd.org/cgi/man.cgi?query=zpool-features&sektion=7&manpath=FreeBSD+11-current <tt>zpool-features(7)</tt>] (FreeBSD).
OpenZFS feature flags – an alternative to traditional version numbering – allow '''a uniquely named ''pool property'' for each change to the on-disk format'''. This approach supports:  


For greatest compatibility, features that are exclusive (when enabled) should be periodically ported to all other distributions.
* format changes that are independent
* format changes that depend on each other.  


== Feature Flags Implementation ==
== Compatibility ==
The current state of OpenZFS feature flags implementation is in the following table.
 
Where all ''features'' that are used by a pool are supported by multiple implementations of OpenZFS, the on-disk format is portable across those implementations.
 
Features that are exclusive when enabled should be periodically ported to all distributions.
 
== Reference materials ==
 
[http://web.archive.org/web/20160419064650/http://blog.delphix.com/csiden/files/2012/01/ZFS_Feature_Flags.pdf ''ZFS Feature Flags''] (Christopher Siden, 2012-01, in the Internet Archive Wayback Machine) in particular: "… Legacy version numbers still exist for pool versions 1-28 …".
 
[http://illumos.org/man/5/zpool-features <tt>zpool-features</tt>](5) – illumos
 
[https://www.freebsd.org/cgi/man.cgi?query=zpool-features&sektion=7&manpath=FreeBSD <tt>zpool-features</tt>](7) – FreeBSD
 
== Feature flags implementation ==


{| class="wikitable"
{| class="wikitable"
Line 139: Line 153:
* yes = implemented
* yes = implemented


Table original source: [http://blog.vx.sk/archives/44-OpenZFS-Feature-Flags-Compatibility-Matrix.html ''OpenZFS Feature Flags Compatibility Matrix''] at blog.vx.sk
Source: [http://blog.vx.sk/archives/44-OpenZFS-Feature-Flags-Compatibility-Matrix.html ''OpenZFS Feature Flags Compatibility Matrix - VX weblog'']
Editor
241

edits

Navigation menu