On Thu, Dec 6, 2018 at 11:20 AM Josh Paetzel <[email protected]> wrote: > > > > On Thu, Dec 6, 2018, at 12:23 AM, Rich via openzfs-developer wrote: > > On Thu, Dec 6, 2018 at 12:19 AM 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. > > > > > > 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. > > > > > > min: enable async_destroy, empty_bpobj, and lz4_compress. I believe all > > > available OpenZFS v5000 implementations support these 3 features, and > > > certainly without at least async_destroy you can get pools very very very > > > cranky. (This would be IllumOS and FreeBSD in the late 2013 range, I > > > don't think there's an analog in the ZoL world that would be widely used, > > > but I believe the ZoL work started with v5000 so it should work on the > > > earliest of releases eg: 0.6.1 in early 2015) > > > > > > none: enable no features at all. Some masochists^H^H^H^H^H^H^H^H^Hpeople > > > may want to manually enable a set of features. > > > > Framing people who disagree with you as masochists conveys more about > > the beliefs and intent than the entire rest of this message. > > > > Please don't claim you want a discussion when you open it with a > > proposal that solves neither of the two problems the original was > > written to address, and include active mocking of those who disagree > > with you. > > > > - Rich > > > > Rich, I apologize for putting the masochists^H^H^H^H^H^H^H^H^Hpeople into my > email. The attempt at humor added nothing to the proposal at all, but > instead only generated confusion and misunderstanding. I actually don't > disagree with -o features=none at all, in fact I might argue that as a > FreeBSD user of 22 years (including 19 years as my desktop OS it might be the > option *I'd* lean towards. ;) (I see I'm unable to resist being lighthearted > about this) [1]
No, I'm sorry, that's completely reasonable - it was a negative interpretation by me from a combination of what I saw in the contents and the levity, and I should have at least read the meeting notes (assuming they include bits about this) before assuming bad faith. (I, too, usually am unable to avoid levity in otherwise dry messages, and should have just taken it as such, but for some reason, I couldn't convince myself to see it that way.) > The idea of "let's make it so there's a way to override the default of all > features enabled when doing zpool create" had universal support. > > The need to create a pool with no features enabled at all had universal > support. (If nothing else, this could be needed as a QA/Dev feature) I believe -d already does that, on ZoL and I thought everywhere else. > The ability to create a pool that had compatibility with other ZFS > implementations had universal support. [2] > > Your entire email was talked about and considered, but we wanted to start > with just the first idea, which was zpool creation. (The zpool creation part > of your email had seemingly universal support) Please don't take the > omission of the other points in your email as reflective of my personal > opinion of their value. If you'd like I can reply to you offlist with my > "you have several valid points, here's what I'd do if I were King." response > to your email. I'd be interested to know what that would be, but that's just personal curiosity. > [1] Oops, I did it again. > > [2] This point generated the most discussion. What should the compatibility > goals be? Is it realistic for users to type in a list of every OS they want > to be compatible with? If so how do we map the OS to features? My email is > just a starting point for a discussion because there were *a lot* of opinions > about this. The problem with getting feedback on a conference call is there > are personality types that take time to mull over ideas and they tend to get > bulldozed by the "decide now and speak" crowd. Hence the email. > > [3] I actually do have opinions on this topic, but those opinions have been > formed in part by many many late nights of getting ZFS pools back to good. I > can't tell you how many "I did zfs destroy tank/bigdataset, the system > appeared to hang, so I rebooted it and it's been importing the pool for 7 > hours now, please help" calls I've been on. So yes, in my opinion > async_destroy is not an optional feature for using ZFS to store and access > data as a user. I did try to keep my opinions from influencing the proposal > (which once again is a starting point for a discussion), because I certainly > have more! (however the async_destroy one did indeed bleed through!) Sure, async_destroy/empty_bpobj/lz4_compress are probably a reasonable baseline, since every (stably versioned) implementation of v5000 I'm aware of shipped them (and the v28 compat boat burned down a while ago), I just disliked the idea of initially special-casing them and then (most likely) ending up with having to explicitly specify all your defaults anyway from concerns that the defaults might change moving forward. Once again, my apologies for assuming bad faith; I tried to put it down for a bit and revisit it to be sure I wasn't just reading things that weren't there, but still managed to reach the wrong conclusion. - Rich ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T562a2f6ecf883736-M03e4e1bbcabbe075ea4c9973 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
