On Fri, Dec 7, 2018 at 12:50 PM Richard Elling < [email protected]> wrote:
> <devil's advocate> > People don't read man pages, so they won't read about this option or any > of the other options. > For those people who do read man pages, we can simply document the > appropriate flags > and their shortcut aliases. > > But... people don't read man pages and once the pool is created, it is too > late to go back and > read the man page. > </devil's advocate> > That's a fair point. I think it will be addressed when/if we change the default: > 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. > The good news is, we can make man page changes now. Section "HOW TO CREATE > AN > OS-PORTABLE POOL" > Yes please! --matt > -- richard > > On Dec 7, 2018, at 11:15 AM, Matthew Ahrens <[email protected]> wrote: > > On Fri, Dec 7, 2018 at 10:49 AM Jason King via openzfs-developer < > [email protected]> wrote: > >> Are there any concerns this might become a bit unwieldy over time? I’m >> undecided on this myself, but thought it’d be worth raising the question. >> >> Just as a data point, had this existed when ZFS was first publicly >> released (Nov 2005 is the date I can find), that would mean 13 >> ‘portable-XXX’ values, plus ‘portable’ (though a number of values might be >> equivalent) today. >> > > I don't think so. The fact that there are N yearly values doesn't place > much cognitive burden on users. We'll want to make sure the implementation > gathers this info into one place but it can probably just be one giant > table that we add an entry to each year. We can retroactively create > entries starting from 2013 or 2014 (feature flags were introduced May 2012). > > --matt > > >> >> >> >> From: Matthew Ahrens <[email protected]> <[email protected]> >> Reply: openzfs-developer <[email protected]> >> <[email protected]> >> Date: December 7, 2018 at 12:14:17 PM >> To: openzfs-developer <[email protected]> >> <[email protected]> >> Subject: Re: [developer] OpenZFS feature flag at zpool create proposal >> >> >> >> On Thu, Dec 6, 2018 at 11:17 AM Matthew Ahrens <[email protected]> >> wrote: >> >>> >>> >>> On Thu, Dec 6, 2018 at 10:06 AM Josh Paetzel <[email protected]> wrote: >>> >>>> >>>> >>>> >>>> On Thu, Dec 6, 2018, at 11:40 AM, Matthew Ahrens wrote: >>>> >>>> >>>> >>>> On Wed, Dec 5, 2018 at 9:21 PM Josh Paetzel <[email protected]> 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 <https://openzfs.topicbox.com/latest>* / openzfs-developer / see > discussions <https://openzfs.topicbox.com/groups/developer> + participants > <https://openzfs.topicbox.com/groups/developer/members> + delivery options > <https://openzfs.topicbox.com/groups/developer/subscription> Permalink > <https://openzfs.topicbox.com/groups/developer/T562a2f6ecf883736-Mbf72f5742048b6ce0f8b21cf> > ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T562a2f6ecf883736-Mb57eafb1131536533198bcb3 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
