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)