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
- zfs send with the avoidance of feature flags that would be
unsupported by the other side
- zfs recv with the ability to avoid flipping feature bits that would
result in the pool not being importable by something
- zpool create not defaulting to all flags on as a reasonable change
without significant negative impact
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
