<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> The good news is, we can make man page changes now. Section "HOW TO CREATE AN OS-PORTABLE POOL" -- richard > On Dec 7, 2018, at 11:15 AM, Matthew Ahrens <mahr...@delphix.com> wrote: > > On Fri, Dec 7, 2018 at 10:49 AM Jason King via openzfs-developer > <developer@lists.open-zfs.org <mailto:developer@lists.open-zfs.org>> 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 <mahr...@delphix.com> <mailto:mahr...@delphix.com> > Reply: openzfs-developer <developer@lists.open-zfs.org> > <mailto:developer@lists.open-zfs.org> > Date: December 7, 2018 at 12:14:17 PM > To: openzfs-developer <developer@lists.open-zfs.org> > <mailto:developer@lists.open-zfs.org> > Subject: Re: [developer] OpenZFS feature flag at zpool create proposal > >> >> >> On Thu, Dec 6, 2018 at 11:17 AM Matthew Ahrens <mahr...@delphix.com >> <mailto:mahr...@delphix.com>> wrote: >> >> >> On Thu, Dec 6, 2018 at 10:06 AM Josh Paetzel <j...@tcbug.org >> <mailto: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 >>> <mailto: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 <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-M0f226367350221daa7b1b98d> ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T562a2f6ecf883736-Mbf72f5742048b6ce0f8b21cf Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
