This email is a summarization of the current proposal for easing the task of
creating OS portable pools with zpool create. There's been a ton of discussion
around this feature and we wanted to summarize the current discussion in
preparation for tomorrow's meeting:
Add new options to "zpool create", "zpool upgrade", and "zpool set":
- zpool create -o features=portable-20XX (yearly values)
- zpool create -o features=portable
- zpool upgrade -o features=portable-20XX
- zpool upgrade -o features=portable
- zpool set feature@portable=20XX
- zpool set feature@portable=enabled
"-o features=portable-2016" means features that were supported by all tier-1
platforms at the beginning of 2016. This
definition will not change over time. Specifically, on January 1, 2016, the
following all supported the features:
- a numbered release of FreeBSD (specifically FreeBSD 10.2 for
portable-2016)
- a numbered release of ZFSonLinux (specifically ZoL 0.6.5.3 for
portable-2016)
- the code in illumos-gate as of 1 year prior (specifically Jan 1 2015 for
portable-2016).
Similar yearly portable values will be created at the beginning of each year.
(Side note: the 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.)
"-o features=portable" means that features that are currently supported by all
tier-1 platforms. This definition will change over time. Specifically, as of
the current date, the following all supported the features:
- a numbered release of FreeBSD (currently FreeBSD 11.2)
- a numbered release of ZFSonLinux (currently ZoL 0.7.12)
- the code in illumos-gate as of 1 year prior (currently December 7, 2017,
commit b8e5ecd6 for bug 8895).
>From these definitions, users can make the following conclusions:
- I upgraded this machine sometime in 2017, therefore if I want to bring a
pool to it, I can use "-o features=portable-
2017" or earlier.
- I case of an emergency or change in strategy, I want to be able to bring
this pool to another operating system. I can
upgrade or install the other OS when I need to. Therefore I can use "-o
features=portable".
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.
"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.
For now the default behavior of "zpool create" remains the same. If we find
something that we think works well then a future consideration would be making
"zpool create" imply "-o features=portable" by default, and "zpool upgrade
<pool>|-a" imply "-o features=portable" by default.
This proposal as it sits applies to data pools only. Portability of boot pools
is currently not a consideration.
--
Thanks,
Josh Paetzel
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/Td66d70a086ae5a9e-M479ea9418dc7518cd53a07fc
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
