A little late to the party, but:
Given the goals are to give an easy way to create a pool that is compatible
with a desired range of other systems (and tools like GRUB) in a way that is
both interoperable between the different distributions / platforms, easy to
automate and simple to remember...
I propose something similar to how legacy pools version<5000 / SPA_VERSION
worked, just that there won't be one vendor that bumps the version with each
new feature implemented but OpenZFS maintaining that list and only adding a new
entry (and increasing the maximum supported 'feature_level' over all of
OpenZFS, just to tack a name onto it for the moment) when availability of a new
feature is archieved on _all_ platforms.
This would IMHO simplify feature interoperation quite drastically, as any
system (regardless of platform, distribution, ...) at a certain feature_level
would guarantee availability of a defined feature set. And a maximum number to
support all system one supports is way easier to remember for most than a list
of feature names - and way quicker and less error prone to type.
Bonus points for sorting all existing features already supported on every
platform in a way that the first ones (with the lowest numbers) are the ones
all zfs aware bootloaders on all zfs platforms support (resulting in something
like feature_level=5 being compatible with grub and, in an ideal world,
whatever exists on BSD, macOS and Illumos to boot from a zfs pool).
Adding a platform agnostic way to query the maximum supported feature_level of
a system, which could well be a simple /etc/zfs/feature_level file (just
containing the numeric level) that gets installed with supporting ZFS versions
(and can easily be echo'd into older installs to make them compatible). Then
one (or a script) could quickly look at multiple systems, just memorize the
lowest seen number and end up with the maximum feature_level a pool can have to
support all these systems.
OpenZFS could provide a quite trivial helper script that converts a
feature_level to a string of "-o feature@<name>=enabled" (that could be
directly used in "zpool create `zfs-feature-level 9` ...") which would be easy
to install on older systems (and in more modern versions be called into from
eg. "zpool create --feature-level=9").
Second operation of that helper could be (when not given a one-argument
integer) to return the minimal feature_level for a set of specified features
("zfs-feature-level <feature name> ..." => "9"). This could also be used to
handle any 'portable', 'compatX', 'release-YYYY-MM', 'distribution-x-version-y'
(or whatever people might see the need for) tags - and as it idealy would be a
script (bash, or something that's available on all systems) it would be easy to
tweak to add support custom user specific tags ('crap-machine-in-cellar').
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/T562a2f6ecf883736-M6f447236d7f119901d644891
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
