On Thu, Dec 6, 2018 at 11:17 AM Matthew Ahrens <mahr...@delphix.com> wrote:
>
>
> On Thu, Dec 6, 2018 at 10:06 AM Josh Paetzel <j...@tcbug.org> wrote:
>
>>
>>
>>
>> On Thu, Dec 6, 2018, at 11:40 AM, Matthew Ahrens wrote:
>>
>>
>>
>> On Wed, Dec 5, 2018 at 9:21 PM Josh Paetzel <j...@tcbug.org> wrote:
>>
>> There was a proposal on this mailing list a week or so ago that sparked
>> some good discussion regarding setting feature flags at pool creation. We
>> discussed this proposal on the last OpenZFS call and while we all agreed it
>> was a good idea, we felt the UI could use a little workshopping.
>>
>>
>> Thanks for leading this discussion, Josh!
>>
>>
>>
>> This proposal is simply a starting point for a discussion.
>>
>> The proposal is to add an optional flag at zpool create time. -o
>> features=
>>
>> which can be set to one of the following 4 settings:
>>
>> all: The default and the current behavior of zpool create. This setting
>> enables all features supported by the in use OpenZFS version.
>>
>> compat: Enable async_destroy, empty_bpobj, filesystem_limits,
>> lz4_compress, spacemap_histogram, extensible_dataset, bookmarks,
>> enabled_txg, and hole_birth. This set of features is supported by
>> FreeBSD/FreeNAS 9.3 (July of 2014), ZoL 0.6.4 ( 0.6.5.6 was used in Ubuntu
>> 16.04 LTS), and Illumos in the early to mid 2014 era.
>>
>>
>> I think the term "portable" is more specific than "compat[ible]", so "-o
>> features=portable" is probably a better name. Thanks to whoever suggested
>> that at the meeting Tuesday.
>>
>>
>> +1
>>
>> I think that the definition of "-o features=portable" needs to change
>> over time, as features become more widely available. Do you have thoughts
>> on how specifically we should do that?
>>
>>
>> One thought would be: As a delivery vehicle drops out of support we can
>> remove it from the list. So say we have -o features=portable include
>> Ubuntu 16.04 LTS. When support for Ubuntu 16.04 LTS expires we remove it
>> from the portable list. Now, that directly contradicts the first pass at
>> this. For instance FreeBSD (and FreeNAS) 9.3-R have long been out of
>> support by the "vendor"
>>
>
> I think that's a very conservative way to define it - essentially: you
> "portable means you can take this pool to any FreeBSD or Ubuntu that's
> supported by the vendor". I would suggest we look at it from the other
> direction: "portable means that there's some version of FreeBSD, ZoL, and
> illumos that you can take your pool to". More specifically we could say
> "it's in a released version of FreeBSD (e.g. FreeBSD 11.1), a released
> version of ZoL (e.g. Zol 0.7.2), and in the illumos master branch" (since
> there's no "releases" of illumos). That said, I'm open to variations on
> this (e.g. should we say it's in a SmartOS release rather than illumos
> master? Or it's in FreeBSD-STABLE vs a numbered release?)
>
>>
>>
Here's a more detailed proposal:
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.
"-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".
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.
For now, I would be most comfortable with the default behavior of "zpool
create" remaining the same. If we find something that we think works well
then I'd consider making "zpool create" imply "-o features=portable" by
default, and "zpool upgrade <pool>|-a" imply "-o features=portable" by
default.
--matt
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/T562a2f6ecf883736-M9860ca063c98d9793c5434cc
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
