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

From: Mark Millard via freebsd-current <freebsd-current_at_freebsd.org>
Date: Wed, 15 Dec 2021 01:21:16 UTC
On 2021-Dec-14, at 16:54, Alexander Motin <mav@FreeBSD.org> wrote:

> 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.

I presume that because of FreeBSD's releng/13.0 and stable/13 (and
releng/13.? futures) that:

/usr/share/zfs/compatibility.d/openzfs-2.1-freebsd

will never have edonr added to the file. Sound right?

Is there going to be a /usr/share/zfs/compatibility.d/openzfs-2.*-freebsd*
that has edonr as well (instead of using a openzfs-2.1-linux file for
such)? If yes, when does the file show up? Does main get drafts of the
file over time until there is a releng/14.0 that would have the final
version?

> 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)