On Sun, Dec 9, 2018 at 5:46 PM <[email protected]> wrote:
> 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
>
I think some of what you're talking would be addressed by an extension to
my proposal:
<context from my previous message:>
I think a reasonable addition to this would be to remember the last
"features=" value that was used with "zpool create" or "zpool upgrade". If
it's a static value (portable-20XX), "zpool upgrade" would not do anything
unless you give a force flag. If it's the dynamic value
("features=portable") then "zpool upgrade" would require a force flag
unless we're enabling a feature that's allowed by the current definition of
"portable". So running "zpool upgrade <pool>" or "zpool upgrade -a" would
always be "safe" in that it respects the "features=portable*" setting last
made.
<extension:>
Additionally, "zpool status" would only alert if "zpool upgrade <pool>"
would do something. I.e. If you did "features=portable-20XX", then "zpool
status" would never tell you about unavailable features. If you did
"features=portable", then when you upgrade to newer software that has
additional "portable" features, then "zpool status" would prompt you to
upgrade.
Side note: my proposal is for "features=portable" to be able to have
additional features beyond "features=portable-<currentyear>". I.e. it can
change throughout the year. On January 1st, we would add
"features=portable-<currentyear>" which would have the definition as
"features=portable" on January 1, but remain static.
--matt
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/T562a2f6ecf883736-M4760604f6a2a441139464283
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
