Difference between revisions of "Feature Flags"

From OpenZFS
Jump to navigation Jump to search
(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'']

Revision as of 17:09, 4 February 2017

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.

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.

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:

  • format changes that are independent
  • format changes that depend on each other.

Compatibility

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

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 …".

zpool-features(5) – illumos

zpool-features(7) – FreeBSD

Feature flags implementation

Feature flag FreeBSD ZFS on Linux OpenZFS OSX OmniOS
8.4 9.3 10.2 r283009 0.6.5 1.4.5 r151014
async_destroy yes yes yes yes yes yes yes
empty_bpobj yes yes yes yes yes yes yes
lz4_compress yes yes yes yes yes yes yes
multi_vdev_crash_dump no yes yes yes no no yes
spacemap_histogram no yes yes yes yes yes yes
enabled_txg no yes yes yes yes yes yes
hole_birth no yes yes yes yes yes yes
extensible_dataset no yes yes yes yes yes yes
embedded_data no no yes yes yes yes yes
bookmarks no yes yes yes yes yes yes
filesystem_limits no yes yes yes yes yes yes
large_blocks no no yes yes yes yes yes

Table legend

  • no = not implemented
  • yes = implemented

Source: OpenZFS Feature Flags Compatibility Matrix - VX weblog

Retrieved from "https://openzfs.org/w/index.php?title=Feature_Flags&oldid=2232"