Joyent plans to import this into SmarOS but it is on hold:
"Yes, we do intend to pull this in as soon as it's merged in OpenZFS.
There are still some outstanding reports of issues there and a full
in-depth review pending. The on-disk format change late last year didn't
increase confidence, either, so we're being cautious. It's important to
note that ZoL have not yet made a *release* with encryption support
(it's only in master), and their standards of testing and assurance for
releases are most similar to what we require for "master" on our repos
I don't know if FreeBSD is going to do the same as Joyent though.
BSD & ZoF importance for ZoL project might have just greatly improved. Seems like ZoL is not usable with Linux 5.0 kernel due to internal API changes. Of which Linux kernel top brass are completely unwilling to fix. NIH syndrome at it's best.
[I]On Thu, Jan 10, 2019 at 07:07:52PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-01-10 17:32:58 [+0000], Hutter, Tony wrote:
> > > But since when did out-of-tree modules use __kernel_fpu_begin? It's an
> > > x86-only thing, and shouldn't really be used by anyone, right?
> > ZFS on Linux uses it for checksums. Its removal is currently breaking ZFS builds against 5.0:
> So btrfs uses crc32c() / kernel's crypto API for that and ZFS can't?
> Well the crypto API is GPL only exported so that won't work. crc32c() is
> EXPORT_SYMBOL() so it would work.
> On the other hand it does not look right to provide a EXPORT_SYMBOL
> wrapper around a GPL only interfaceâ€¦
Yes, the "GPL condom" attempt doesn't work at all. It's been shot down
a long time ago in the courts.
My tolerance for ZFS is pretty non-existant. Sun explicitly did not
want their code to work on Linux, so why would we do extra work to get
their code to work properly?
I should've said "experience" instead of "implementation", because it'll still be developed by the same developers. It won't affect the in-kernel ABI/API integration and stability FreeBSD has - and this integration is shipped by default. AFAIK, no Linux distribution has this.
The only difference is that the ZoL repository is used for development due to the rate of contributions there. However, I still object this decision for reasons i won't get into again.
That was my concern as well. But after watching a recent openZFS meet up. The developers proposed the idea of having a central, 'agnostic' repository with sub-repos containing operating system 'implementations' of openZFS. That way each system can their go their way whilst keeping all new features and bug fixes easily accessible from that 'agnostic' repo.
Now, will the Linux devs keep their feature innovations and bug fixes OS-agnostic? Who knows. Will they keep their word on this approach? Who knows.
IMO, I think they will weasel their way into the innards of the API and control this 'agnostic' repo.