ZFS ZFS features annoyance.

When I try to import a zpool from a FreeBSD 13.0, to Devuan-Linux kernel 4.19 I receive :
root@yyy:~# zpool import -f ZUSB
This pool uses the following feature(s) not supported by this system:
com.delphix:spacemap_v2 (Space maps representing large segments are more efficient.)
org.zfsonlinux : project_quota (space/object accounting based on project ID.)
com.delphix:log_spacemap (Log metaslab changes on a single spacemap and flush them periodically.)
All unsupported features are only required for writing to the pool.
The pool can be imported using '-o readonly=on'.
cannot import 'ZUSB': unsupported version or feature

Import in void-linux kernel 5.11 works fine.
 
Why ask on a BSD forum when you're using Linux?

Bottom line: they're apparently not compatible and I am not surprised because although I don't use Linux I believe that they're using "OpenZFS" because the official port to FreeBSD wasn't good enough (?) and thus stuff got rewrited.

I may not be 100% correct on the above in detail but I do think this is the underlying cause of your problems: incompatibility. There's ZFS and OpenZFS these days.
 
Wrong.
And I did not asked a question. I was sharing experience.
Problem with zpools is you can upgrade featuresets but not downgrade ...
Please note OpenZFS (kldload openzfs) uses the same codebase as the one used on Linux.
Versus zfs (kldload zfs) which used the codebase of openindiana(solaris)
Bottomline, when the zfs-version or featureset is the same there is no problem at all and they are compatible.
 
Linux kernel version doesn't matter, OpenZFS is not in the mainline kernel. You basically need to update your ZFS on Devuan to get full compatibility.

FreeBSD 13 does include support for draid and if you actually make vdevs with draid, it's not importable with OpenZFS 2.0.x on Linux. OpenZFS 2.1.x will be fine.

Also FreeBSD doesn't support edonr, so creating pools from the Linux side might have the potential to make them un-importable from FreeBSD (if that feature becomes active on the pool). You can always use "-o feature@edonr=disabled" to make sure it doesn't happen. Even in the draid case, you can use "-o feature@draid=disabled" if you don't need it.
 
Also because, according to 3rd party sources (who actually use Linux, I don't), ZFS on Linux is deemed a lot more inferior than what you get on FreeBSD, by them at least.

I’m not sure what to make of this, given that 13.0 is on the OpenZFS (née ZFS on Linux) 2.0 codebase.

Here’s the feature matrix you can refer to: http://build.zfsonlinux.org/zfs-features.html. Do you know what version of ZoL Devuan is running? You can create a pool with zpool create -d to start with features disabled, and only enable those you want. (There is active work ongoing to standardize some “legacy” levels of zpool creation when backward-compatibly is required.)
 
Bottom line: they're apparently not compatible and I am not surprised because although I don't use Linux I believe that they're using "OpenZFS" because the official port to FreeBSD wasn't good enough (?) and thus stuff got rewrited.
The history of ZFS traces from Solaris to illumos, from there to FreeBSD and "OpenZFS/ZFS on Linux" separately, and has ended up with the "re-uniting" of the FreeBSD and Linux codebases in OpenZFS 2.0 (excluding illumos for the moment, but potentially including MacOS and Windows in the future).

I think you mean the right things, but what you say was true only until 2020 (and arguably, the ZFS-on-Linux codebase was more advanced in the end than the FreeBSD codebase coming down from illumos).

So, bottom line: There should be no feature differences between any FreeBSD above 13.0, and any Linux using OpenZFS 2.0 or above. Which brings us to:
When I try to import a zpool from a FreeBSD 13.0, to Devuan-Linux kernel 4.19 I receive :
[…]
Import in void-linux kernel 5.11 works fine.
Since ZFS is never part of the kernel in Linux (except through DKMS), the kernel versions are not very relevant here. What you've looking for is the version of the ZFS package (whatever it's called).

You'll probably find that your Devuan has some version pre-2.0, and your void-linux has 2.0+. In the future, just make sure any Linux you use has OpenZFS 2.0 or above, and you should be good to share pools with any FreeBSD 13.0 or above.
 
True. I tried to upgrade Devuan and but then other stuff broke.
But interesting can import zpools in readonly mode, "zpool import -o readonly=on ".
 
True. I tried to upgrade the kernel in Devuan and then zfs broke because probably the zfs code there is only for kernel 4.
But interesting can import zpools in readonly mode, "zpool import -o readonly=on ".
Your error message already told you that :)
This pool uses the following feature(s) not supported by this system:
com.delphix:spacemap_v2 (Space maps representing large segments are more efficient.)
org.zfsonlinux : project_quota (space/object accounting based on project ID.)
com.delphix:log_spacemap (Log metaslab changes on a single spacemap and flush them periodically.)
All unsupported features are only required for writing to the pool.
The pool can be imported using '-o readonly=on'.
It's more of a lucky coincidence in this case, rather than a general rule, but sometimes it works out with incompatible features still allowing a readonly-import. Very considerate of ZFS :)
 
The history of ZFS traces from Solaris to illumos, from there to FreeBSD and "OpenZFS/ZFS on Linux" separately, and has ended up with the "re-uniting" of the FreeBSD and Linux codebases in OpenZFS 2.0 (excluding illumos for the moment, but potentially including MacOS and Windows in the future).
ZFS became part of FreeBSD around 2007. Illumnos was first released around 2010 or 2011, so this story seems bogus. OpenSolaris on the other hand had something to do with all this but not in the sequence you picture here.

Anyway, seems I made a mess of things in this thread because I used an ignore vs. unwatch, re-read after a ping and got confused, removed a post of mine which seemedd to dangle in the open, and yah.
 
As I understand it, FreeBSD’s 9 (?) …12 implementation started from OpenSolaris’s and then followed (and contributed back to) Illumos (itself a fork of OpenSolaris) development when OS closed up.

ZoL also was initially based off the OpenSolaris version, but developed lots of new features; some were brought back to illumos and FreeBSD, but that route became harder and harder as code bases diverged, and with 13 the choice was made to re-base FreeBSD’s ZFS code on ZoL (renamed to OpenZFS 2.0 to reflect the not-just-for-Linux development efforts going forward.)

FreeBSD is now a first-tier platform (in the CI systems; along with Linux) for OpenZFS, so it will be much easier to keep synchronized with OpenZFS (as any breaking changes are found and can be addressed right away, rather than N months down the line.)
 
The pool can be imported using '-o readonly=on'.
That is the answer.

Create another pool on that machine with native zfs version, import this pool readonly and use zfs send to transfer it.

... and if you do not have snapshots on it, connect it back to FBSD 13.0, create recursive snapshots on it, and return to the procedure.

And the other way around, you can create a pool on that Linux machine and try to import it to FreeBSD. Just import, do not upgrade.
 
That has always been the issue with upgrading a pool, even on if you are just sticking with FreeBSD. You may not be able to go back kernel versions.
Boot environments with ZFS are very powerful, a very good/easy way to do system upgrades like 9 to 10 to 11 to 12. When you do so, you will often get that message regarding pools. But if you are running 12.2 and do zpool upgrade, you may lose the ability to use your 9/10/11 BEs in a meaningful way. So a lot of folks using BEs do their system update, run the new version long enough to convince themselves it's stable, delete old BEs, then do zpool upgrade.

Of course, one never has to actually upgrade a zpool. If you don't need the new features, there is little or no downside of leaving it alone.

As you found out, creating a zpool on any system always enables the full set of features that version understands, rendering it a problem with other systems not running that same or higher version. Sharing zpools always create with the lowest common denominator and don't upgrade them.
 
You want zpool upgrade -v to look at the supported feature flags. You can also use the matrix I mentioned earlier to compare across systems you don't have access to.

The output looks like this:
Code:
$ zpool upgrade -v
This system supports ZFS pool feature flags.

The following features are supported:

FEAT DESCRIPTION
-------------------------------------------------------------
async_destroy                         (read-only compatible)
     Destroy filesystems asynchronously.
empty_bpobj                           (read-only compatible)
     Snapshots use less space.
lz4_compress
     LZ4 compression algorithm support.
multi_vdev_crash_dump
     Crash dumps to multiple vdev pools.
<snip>
 
After some testing Freebsd-13 ; Void-Linux & Devuan-Testing-Chimaera are on version zfs-2.0.X and seem to be fully compatible.
 
  • Like
Reactions: mtu
Back
Top