Date: Tue, 14 Dec 2021 19:00:41 -0800 From: Mark Millard via freebsd-current <freebsd-current@freebsd.org> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-current <freebsd-current@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status Message-ID: <0C484963-D833-4B12-A9C8-8FADC0EF1D9B@yahoo.com> In-Reply-To: <bcd15948-7964-5e5c-6e4b-13d50516e27f@FreeBSD.org> References: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4.ref@yahoo.com> <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> <ae149ace-0ca2-ebf9-8f96-ac5b7569f14f@FreeBSD.org> <B15A2BF9-2CC4-490D-BC83-1AB0A9C94005@yahoo.com> <bcd15948-7964-5e5c-6e4b-13d50516e27f@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >> /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd >>=20 >> will never have edonr added to the file. Sound right? >=20 > 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? >=20 > 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. (=46rom 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 : >>>>=20 >>>> # 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 >>>>=20 >>>> So I've taken to updating my existing zpool's via: >>>>=20 >>>> zpool set compatibility=3Dopenzfs-2.1-freebsd NAME >>>>=20 >>>> because I use them under releng/13 and stable/13 and main >>>> and do not want edonr accidentally enabled. >>>>=20 >>>> It is not obvious to me if edonr being present for main >>>> is deliberate or not. >>>>=20 >>>> For reference: >>>>=20 >>>> # 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 >>>>=20 >>>> I happened to do this activity in a aarch64 context, in >>>> case that matters. >>>=20 >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0C484963-D833-4B12-A9C8-8FADC0EF1D9B>