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

On 14.12.2021 20:21, Mark Millard wrote:
> 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?

FreeBSD stable/13 is tracking still alive upstream zfs-2.1-release
branch.  It is still updated periodically, but primarily with bug fixes.

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

FreeBSD main though tracks openzfs master branch, and as a moving target
it has no compatibility definitions.  I'd expect by the time of FreeBSD
stable/14 branching there to be some new openzfs branch it could switch
to, but so far AFAIK there were no specific announcements yet.  And
enabled edonr is a step toward not differentiating FreeBSD and Linux
compatibility settings any more.

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