Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status

On 2021-Dec-14, at 16:36, Mark Millard <marklmi@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)