Feature Flags
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.
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 more details see these slides (Jan 2012) and zpool-features(5) (illumos) or zpool-features(7) (FreeBSD).
For greatest compatibility, features that are exclusive (when enabled) should be periodically ported to all other distributions.
Feature Flags Implementation
The current state of OpenZFS feature flags implementation is in the following table.
Feature flag | FreeBSD | ZFS on Linux | OpenZFS OSX | OmniOS | ||
---|---|---|---|---|---|---|
8.4 | 9.3 | 10.1 | 0.6.4 | 1.3.1 | r15104 | |
async_destroy | yes | yes | yes | yes | yes | yes |
empty_bpobj | yes | yes | yes | yes | yes | yes |
lz4_compress | yes | yes | yes | yes | yes | yes |
multi_vdev_crash_dump | no | yes | yes | no | no | yes |
spacemap_histogram | no | yes | yes | yes | yes | yes |
enabled_txg | no | yes | yes | yes | yes | yes |
hole_birth | no | yes | yes | yes | yes | yes |
extensible_dataset | no | yes | yes | yes | yes | yes |
embedded_data | no | no | yes | yes | yes | yes |
bookmarks | no | yes | yes | yes | yes | yes |
filesystem_limits | no | yes | yes | no | no | yes |
large_blocks | no | no | no | no | no | yes |
Table legend
- no = not implemented
- yes = implemented