Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status
- Reply: Alexander Motin : "Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status"
- In reply to: Alexander Motin : "Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 15 Dec 2021 03:00:41 UTC
On 2021-Dec-14, at 17:35, Alexander Motin <mav@FreeBSD.org> wrote: > 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. I infer from the above that: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd is unlikely to be changed to be inaccurate relative to releng/13.0 , at least as long as 13.0 is a supported FreeBSD release, but probably for all the releng/13.? . >> 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. I infer from the above that it will be much closer to releng/14.0 's time frame before there will be an additional: /usr/share/zfs/compatibility.d/openzfs-*-freebsd* ( or a name that does not even mention freebsd or linux but applies to releng/14.0 ). Good to know. I could imagine FreeBSD having links with names making it clear what each FreeBSD release should use for a matching feature-list file when one is desired. For example: # ln -s openzfs-2.1-freebsd openzfs-freebsd-13.0-RELEASE I had to do multiple comparisons to know for sure what file to use to have a match: it was not obvious from my background knowledge. (From what you have reported, I'd not expect stable/* or main to have such links.) Thanks for the information. I know better what to do now. >>> 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)