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 01:21:16 UTC
On 2021-Dec-14, at 16:54, Alexander Motin <mav@FreeBSD.org> wrote: > 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. 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 : >> >> # 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)