Date: Tue, 14 Dec 2021 19:54:50 -0500 From: Alexander Motin <mav@FreeBSD.org> To: marklmi@yahoo.com, 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: <ae149ace-0ca2-ebf9-8f96-ac5b7569f14f@FreeBSD.org> In-Reply-To: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> References: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4.ref@yahoo.com> <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ae149ace-0ca2-ebf9-8f96-ac5b7569f14f>