I would say that having the default be 'portable' (which itself may just be an alias to portable-2018 much like compress=on is now LZ4), makes the most sense. If a user wants to use a feature that is not included in that, 'zpool upgrade -o features=all' or specifically enabling individual features is quick and a well understood administrative operation. Whereas currently, creating a compatible pool involves manually listing the features you do or do not want, which is cumbersome.
One thing we'll need to consider, is the 'zpool status' message: status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. We might modify this slightly to warn about the loss of portability that doing the upgrade causes, and maybe not show this message if they are using features=portable-2018 This raises a further question about how to handle when we bump what features=portable means (and how often we do it). When you say upgrade from ZoL 0.8.x to ZoL 0.9.x, the definition of features=portable goes from 2018 to 2020, you probably SHOULD have the 'zpool status' message encouraging you to do a 'zpool upgrade'. There is more to this than I originally thought. ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T562a2f6ecf883736-M336fcf3f3512f0c9be86860d Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
