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 <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.
> >
> > 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]
Your initial email generated enough conversation during this week's leadership
meeting that Matt Ahrens requested someone write a proposal as a starting point
to collapse on a solution.
If I may be so bold as to summarize the discussions your email generated:
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)
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.
[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!)
--
Thanks,
Josh Paetzel
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/T562a2f6ecf883736-Mdb5139422ecff0ef43e96c67
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
