Date: Tue, 14 Dec 2021 17:21:16 -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: <B15A2BF9-2CC4-490D-BC83-1AB0A9C94005@yahoo.com> In-Reply-To: <ae149ace-0ca2-ebf9-8f96-ac5b7569f14f@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Dec-14, at 16:54, Alexander Motin <mav@FreeBSD.org> wrote: > Mark, >=20 > 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=3Dedonr. 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 : >>=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 =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?B15A2BF9-2CC4-490D-BC83-1AB0A9C94005>