On Fri, Dec 7, 2018, at 11:50 AM, Matthew Ahrens wrote:
>
>
> 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[1]* / openzfs-developer / see discussions[2] +
> participants[3] + delivery options[4] Permalink[5]
I support this proposal.
--
Thanks,
Josh Paetzel
Links:
1. https://openzfs.topicbox.com/latest
2. https://openzfs.topicbox.com/groups/developer
3. https://openzfs.topicbox.com/groups/developer/members
4. https://openzfs.topicbox.com/groups/developer/subscription
5.
https://openzfs.topicbox.com/groups/developer/T562a2f6ecf883736-M9860ca063c98d9793c5434cc
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/T562a2f6ecf883736-M92e289421f76a2b00a0fae30
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
