I read the proposal as giving a ZFS admin the QoL to not having to dig through some feature compatibility matrix each time he wants to create a pool that should be importable on a set of other machines.
I'm fine with that general idea. I just see no point (and no benefit) in hardcoding the values. Because even should someone decide to mess up his config file, leading to his pools having strange feature sets, *it will not have any effect at all on **everyone else*. Not giving the ability to do that (be it to create custom definitions that make sense for a use case or even remove features from the 'official' definitions as these have no use - both to the user doing that),without any technical need for it, makes no sense. As no one seems to be interested in working on this (at least from what I gathered from the video): I am willing to implement it as a python helper that can be called into from the zfs userland (so zpool can request the configured list of features for a tag given) and also be used standalone (to list all tags a specified pool should to be compatible with). ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/Td66d70a086ae5a9e-M7411d8d3813f30e11b1d129e Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
