On 2021-Dec-14, at 16:36, Mark Millard <mark...@yahoo.com> wrote:
> I just noticed that main reports that my pools were created
> implicitly matching openzfs-2.1-freebsd (and without
> an explicit compatibility assignment) but, under main, zpool
> import and zpool status for those pools report a new, disabled
> feature. Turns out the issue matches what the diff below shows
> as present for openzfs-2.1-linux but not for
> openzfs-2.1-freebsd :
>
> # diff -u /usr/share/zfs/compatibility.d/openzfs-2.1-[fl]*
> --- /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd 2021-12-07
> 21:23:21.573542000 -0800
> +++ /usr/share/zfs/compatibility.d/openzfs-2.1-linux 2021-12-07
> 21:23:21.581738000 -0800
> @@ -1,4 +1,4 @@
> -# Features supported by OpenZFS 2.1 on FreeBSD
> +# Features supported by OpenZFS 2.1 on Linux
> allocation_classes
> async_destroy
> bookmark_v2
> @@ -7,6 +7,7 @@
> device_rebuild
> device_removal
> draid
> +edonr
> embedded_data
> empty_bpobj
> enabled_txg
>
> So I've taken to updating my existing zpool's via:
>
> zpool set compatibility=openzfs-2.1-freebsd NAME
>
> because I use them under releng/13 and stable/13 and main
> and do not want edonr accidentally enabled.
>
> It is not obvious to me if edonr being present for main
> is deliberate or not.
>
> For reference:
>
> # grep edonr /usr/share/zfs/compatibility.d/*
> /usr/share/zfs/compatibility.d/openzfs-2.0-linux:edonr
> /usr/share/zfs/compatibility.d/openzfs-2.1-linux:edonr
> /usr/share/zfs/compatibility.d/openzfsonosx-1.7.0:edonr
> /usr/share/zfs/compatibility.d/openzfsonosx-1.8.1:edonr
> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.3:edonr
> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.4:edonr
> /usr/share/zfs/compatibility.d/ubuntu-18.04:edonr
> /usr/share/zfs/compatibility.d/ubuntu-20.04:edonr
> /usr/share/zfs/compatibility.d/zol-0.7:edonr
> /usr/share/zfs/compatibility.d/zol-0.8:edonr
>
> I happened to do this activity in a aarch64 context, in
> case that matters.
>
Hmm. After (re-)import zpool status seems to track the
compatibility assignment: no complaint in . . .
# zpool import -f -N -R /zamd64-mnt -t zamd64 zpamd64
# zpool status zpamd64
pool: zpamd64
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
zpamd64 ONLINE 0 0 0
gpt/amd64zfs ONLINE 0 0 0
errors: No known data errors
However there is the following (done after the above):
# zpool export zpamd64
# zpool import
. . .
pool: zamd64
id: 4513815084006659826
state: ONLINE
status: Some supported features are not enabled on the pool.
(Note that they may be intentionally disabled if the
'compatibility' property is set.)
action: The pool can be imported using its name or numeric identifier, though
some features will not be available without an explicit 'zpool upgrade'.
config:
zamd64 ONLINE
gpt/amd64zfs ONLINE
This may be expected/intentional but was not obvious expectation
to me.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
