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

From: Alexander Motin <mav_at_FreeBSD.org>
Date: Wed, 15 Dec 2021 00:54:50 UTC
Mark,

Support for edonr checksums was added to FreeBSD main about a month ago:
https://github.com/openzfs/zfs/pull/12735 .  In 13 it is indeed still
not supported.  But you should not worry too much about it, since even
enabled but not activated feature should not cause problems with pool
import by older versions.  And activated it will bcomee only when you
explicitly set for some dataset with checksum=edonr.  Some other
features though activate immediately on enable, but compression and
checksuming algorithms generally should not, with exception to lz4,
which was optional originally, but become default later.

On 14.12.2021 19:36, Mark Millard via freebsd-current 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.
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 
> 

-- 
Alexander Motin