On Mon, Dec 3, 2018 at 12:24 PM Matthew Ahrens <[email protected]> wrote:
>
> On Fri, Nov 30, 2018 at 3:41 PM Rich via openzfs-developer
> <[email protected]> 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.
AIUI, current state is that:
- recv of a stream requiring a feature that's enabled but not active
will switch it to active
- recv of a stream requiring a feature that's disabled but known will just fail
I'd like the ability to avoid some cases of the first one, but as I
think I said before, that's not essential to me, just something that
would be nice to have.
>> - 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.
I'd really like it to default to all-flags-off, just because I've had
way too many instances of people saying "wtf does it enable things
that will break portability by default", and I agree with them -
defaulting to "everything on" is defaulting to pointing the loaded gun
at your foot.
As I said in my first reply, I don't like the idea of defaulting to a
"safe minimum" that increments e.g. annually or otherwise according to
the respective platform release cadences, because then the behavior is
inconsistent depending on how new the machine you created it on is.
(Arguably that was already the default dating back to v28 and prior,
but as adding feature flags addressed in the first place, this is no
longer that world.)
I would prefer an all-off default to a rolling safe minimum default,
but I'd take either of them over the current situation.
For similar reasons, I'd really like to burn the "you can enable more
features" message out of the default zpool status command, because in
practice, a lot of users assume it's reasonable to run by default and
then find out six months later that they did something irrevocable.
I'd strongly prefer zpool upgrade defaulting to whatever
safe-compat-defaults would be used for zpool create in the prior
suggestion, if people find disabled-by-default unpalatable (a/o
likewise taking a -C with the same feature enum code), so that it's
not removed, but the default is not grossly harmful. (Similar to why
zpool add [redundant pool] [single disk] will say "are you sure that's
a good idea, pass -f if so". I'd also take that, but I think
retrofitting that onto an existing command wouldn't be a good user
experience.)
So I think, in order of priority (to me), I'd suggest:
- zpool create not defaulting to all-on feature flags
- zpool status not defaulting to "you should upgrade to enable all
feature flags"
- zpool upgrade not defaulting to all enabled a/o increased warning
that this might be a bad idea
- zpool create -C for filtering what it enables
- zfs send/recv filtering
The first two being the ones I'm set on, as I've seen too many people
burned by them.
- Rich
>>
>>
>> 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 / see discussions + participants + delivery
> options Permalink
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/T04955dd2e8aa4e5d-Ma4b99275d2a8bd55418c45d3
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
