On Fri, Nov 30, 2018 at 3:41 PM Rich via openzfs-developer <
developer@lists.open-zfs.org> wrote:
> Hi all,
> So, I spent a little bit pondering the idea from here [1] of a zpool
> compat flag to allow people to minimize foot-gun interactions when
> creating pools and wanting to migrate them around, and here's what I
> came up with. I'd like comments on it, ideally, before I go cut a
> proof of concept, but without them, I'll probably just go write it and
> submit a PR.
>
> I started off thinking about what the things I wanted most to do with
> this, and came up with:
> - zpool create without fear that you're going to render the pool
> unimportable on platform XYZ
>
Adding your proposed "-C / --compat" flag to zpool create sounds great to
me.
> - zfs send with the avoidance of feature flags that would be
> unsupported by the other side
>
This seems nice to have. It isn't as critical of a problem, since the
receive will fail if it doesn't have the required features enabled.
> - zfs recv with the ability to avoid flipping feature bits that would
> result in the pool not being importable by something
Since the receive won't enable anything, I don't see the need for this.
> - zpool create not defaulting to all flags on as a reasonable change
> without significant negative impact
>
I think this depends greatly on what the specific proposal is. I would not
want to be a few years down the road and we've added lots of features /
performance improvements, but most folks aren't using them because they
created their pools with the default settings.
--matt
>
> I don't know if I'll convince people of 2,3,4, or especially 5, but
> that's what I'd like.
>
> Given that, I'd propose a flag -C on {zpool create, zfs send, zfs
> recv} (since that's only ever already used in zfs project on ZoL
> 0.8.x, that I can find quickly), with usage like:
>
> zpool create -C 'zol0.7,zol0.6.5,freebsd11'
> zfs send -C 'zol0.7,zol0.6.5'
>
> which ends up:
> - calculating a list of supported features for each platform
> enumerated (in my head, a bitmask with AND across all the bitmasks
> enumerated)
> - erroring if you try to (or would need to, for recv) explicitly
> enable a feature incompatible with those in the command (lest we end
> up with people doing zfs send -Lcew -C 'zol0.6.5' and ending up with
> Very Different streams than they expected)
> - for at least zpool create, enabling all the features compatible with
> that least-common-features calculation
>
> send/recv might be contentious for a few reasons, but my logic here is:
> - if a send stream is generated requiring a feature on the receiver,
> and sent to a pool with the feature disabled, receiving a stream into
> that pool without explicit zpool upgrade/zpool set will already fail
> - if a pool has a feature enabled but not active, you'd like a way to
> receive sends without losing whatever backward compat constraints you
> have (e.g. having a feature enabled but not active doesn't mean you
> want something to be able to set it active)
> - if pool1 has a feature active, and you want to backup to pool2 and
> pool3, you'd like a way to readily generate a send stream with the
> least-common-features of pool2 and pool3 without having to
> hand-calculate it, if possible
>
> For zpool create, my logic for the enable-all-possible (and default to
> all-off) with that specification is:
> - zpool create defaulting to all-features-enabled is a recurring
> compat problem for new users who later want to switch/move frequently
> from one platform to another, but they didn't use the correct arcana
> at create time and are stuck until the all-implemented-feature set is
> what they have
> - Making people explicitly enumerate every feature they want to use at
> create time is a mild and error-prone pain, and will only get worse as
> the enumerations get bigger
> - Defaulting to all-features-off is less of a problem for
> managed/expert systems than defaulting to all-features-on is for
> personal/smaller users, but...
> - It'd be useful to both to be able to say "all","none", or "common
> subset of XYZ" without ever-growing parameter lists
>
> That's quite a lot of words for a fairly simple concept, and I don't
> think there's anything I haven't conveyed here about the idea itself,
> but here are two minor thoughts as well:
> - something to print the enumeration of what "featuresets" it knows
> (just names, or names and values), as well as being able to print
> which of those enumerations it is, would probably be useful both for
> people unfamiliar and for tooling to readily be able to do
> create/send/recv -C 'sideA,sideB'
> - I'd really like to rephrase or get rid of the "you can zpool
> upgrade" notice in zpool status by default, because while it says "
> Once this is done, the pool may no longer be accessible by software
> that does not support the features.", people keep running zpool
> upgrade because zpool status mentioned it, even when they didn't need
> any of the new features involved, and are upset when they find out
> what that meant. Maybe make it print that behind an explicit flag so
> people who want that information can still get it, while not handing
> unfamiliar users a sharp tool and suggesting they juggle it.
>
> Anyway, as I said, comments/criticisms welcomed, but please warn me
> before gratuitous flaming, I need to go invest in asbestos
> undergarments before you do that. :)
>
> - Rich
>
> ------------------------------------------
> openzfs: openzfs-developer
> Permalink:
> https://openzfs.topicbox.com/groups/developer/T04955dd2e8aa4e5d-M95668433e3c3454fa90ff5fd
> Delivery options:
> https://openzfs.topicbox.com/groups/developer/subscription
>
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/T04955dd2e8aa4e5d-M000defcb90de48800577e8ae
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
