
The Future of ZFS in FreeBSD - vermaden
https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html
======
b2ccb2
There are some interesting comments further in the mail thread from Matthew
Ahrens (co-creator of ZFS) and Alan Jude (has recently been working on getting
zstandard into ZFS) that give more insight.

Matthew Ahrens[1]:

 _…Being "upstream" is more a matter of degree than an absolute ordering. In
the past, most ZFS features have originated in illumos, and those changes have
been ported to the other platforms (notably FreeBSD and ZoL). Looking forward,
we see more features originating in ZoL. The OpenZFS community (including
FreeBSD) is working to put in place technical processes to ensure that new ZFS
features are available on all platforms. The original post in this thread was
a proposal for how to do that._

Alan Jude[2]:

 _…The way that things have evolved over the last few years means it would be
much more difficult to just import changes from ZoL. ZoL was originally far
behind the OpenZFS repo, but as they were catching up, they were also fixing
bugs and adding features. So there is not really a common point in the source
we could start from to import ZoL commit by commit.… The biggest thing to
remember is that this is still OpenZFS, and still run by the same developers
as it has been. We are just commonizing on the repo that has the most features
integrated into it._

[1] [https://lists.freebsd.org/pipermail/freebsd-
current/2018-Dec...](https://lists.freebsd.org/pipermail/freebsd-
current/2018-December/072431.html)

[2] [https://lists.freebsd.org/pipermail/freebsd-
current/2018-Dec...](https://lists.freebsd.org/pipermail/freebsd-
current/2018-December/072430.html)

------
tivert
> In the past few years the vast majority of new development in ZFS has taken
> place in DelphixOS and zfsonlinux (ZoL). Earlier this year Delphix announced
> that they will be moving to ZoL [https://www.delphix.com/blog/kickoff-
> future-eko-2018](https://www.delphix.com/blog/kickoff-future-eko-2018) This
> shift means that there will be little to no net new development of Illumos.

So, basically, Delphix was a (the only?) commercial user of Illumos and now
they're abandoning it for Linux, which means Illumos will starve for manpower
going forward?

It also sounds like FreeBSD also lacks the resources to maintain an
implementation of something like ZFS, which is ironic since not too long ago
it seemed like one of the marquee features they had that Linux didn't.

~~~
loeg
> It also sounds like FreeBSD also lacks the resources to maintain an
> implementation of something like ZFS, which is ironic since not too long ago
> it seemed like one of the marquee features they had that Linux didn't.

There's no contradiction here. FreeBSD was never the primary contributor to
(Open)ZFS (it was an Illumos thing), but we had the resources to make it a
first class citizen on FreeBSD at a time when Linux wasn't doing that (mostly
for licensing reasons).

It seems like the Linux world has gotten over the licensing problem one way or
another, and at the end of the day Linux has something like 100x-1000x more
developers to bring to bear at the problem. So between that, and illumos'
imminent death, ZoL is the active upstream. FreeBSD is happy to benefit from
the ZFS improvements in ZoL, especially given the collaborative spirit we've
seen from the ZoL team so far. If anything, kudos to the ZoL folks for the
huge amount of effort they've put in over the last handful of years.

~~~
Teknoman117
I just wish the ZFS could be more tightly integrated into Linux than it can
(due to licensing). Would be nice to not have two implementations of a crypto
system, a raid parity computation system, block caching, allocation, etc. Oh
well...

~~~
johnny22
is it just licensing? Doesn't it do its own thing in the vfs layer and perhaps
others in a way that it wouldn't be accepted upstream either way?

~~~
loeg
I don't see any reason ZoL couldn't stub out their own CDDL implementations
and invoke Linux functions directly, where they are a suitable replacement.
The problem is almost always going to be that ZFS was designed for Solaris and
adapting it to use Linux APIs is non-trivial. The code duplication bothers me
less than the page cache duplication / cache reclaim logic integration.

~~~
Teknoman117
It's not just to reduce the amount of ZoL specific work.

If I understand correctly, the developers were saying there are specific parts
of Linux where anything using them is considered a derivative work, and
therefore even distributing source would be a violation of GPL. An instance of
this is the crypto layer that was added in recently with the native dataset
encryption. SPL actually reimplements this logic because the ZoL maintainers
claim they can't use the Linux crypto subsystem without violating GPL.

------
jamieson-becker
The most interesting (and tragic) part of this, to me, is not that ZFS is
being rebased from Illumos (open source Solaris) to ZFS on Linux:

... it's that Solaris is effectively finished as an OS. It's not even its own
upstream anymore for arguably the greatest modern contribution to any OS.

This is tragic, and needless. Oracle effectively shot itself in its own foot
with the pointless and deliberate choice of licenses, the on-again, off-again
open sourcing of Solaris, and the complete lack of commitment. Solaris had a
real shot of remaining a fine alternative UNIX operating system, at least for
the server side of things, but now this shot is gone.

They killed Solaris like they killed Java.

~~~
gruturo
You are assuming they ever even cared about Solaris.

They bought Java, because they were using it everywhere in their own product
offering, and didn't want it under someone else's control (esp. if IBM would
have been Sun's buyer rather than them).

Anything else which came with the purchase (Solaris, OpenOffice, VirtualBox,
MySQL, the hardware business, 30K+ employees) amounted to, in their eyes,
literally strings attached, that they had to pretend to care about for a
while.

Even Java itself is not getting treated too well, but that was never the point
- the point is not to lose control, and to monetize what they can.

------
voltagex_
OT, sort of: I am banned (permanently? [2]) from the #zfsonlinux IRC channel
because I connected to it via IRCCloud [1]. It's this kind of attitude that
worries me about using it.

1: [http://irccloud.com](http://irccloud.com)

2: [https://irc-source.com/channel/freenode/%23zfsonlinux-
quaran...](https://irc-source.com/channel/freenode/%23zfsonlinux-quarantine)

~~~
gsich
They probably don't want another service storing and analysing your messages.

The free version is basically useless: "Stay connected for 2 hours while
inactive (permanent for first 7 days)" because of this.

~~~
voltagex_
Sure, but I can't even reconnect with another client with my normal Freenode
account now.

~~~
mst
Hit up #freenode and see if one of the staff can mediate wih the channel ops
for you - "I was banned by account because irccloud but am happy to use
another client" seems like a reasonable request to me

(I'm freenode staff but currently mostly on hiatus due to lack of tuits)

------
rbanffy
> many races and locking bugs have been fixed in ZoL and never made it back to
> Illumos and thus FreeBSD

Why would that be? Lack of interest on sending them upstream or them being
sent but never merged back?

~~~
rincebrain
I would guess it's because people don't always try to figure out whether bugs
they find that appear to be in Linux-specific code can be reproduced in other
codebases, rather than explicit lack of interest or PRs going nowhere slowly.

~~~
rbanffy
Is there enough interest in ZFS that an organization could be set up to keep a
single core ZFS and coordinate its ports into different OSs in a way all ports
benefit from updates and the frontier between core and OS can be clearer?

~~~
lmm
Well, this mailing list discussion is serving that function; how much more of
an "organization" would you want?

I suppose you could argue for having a single, explicitly OS-independent
"upstream repository" rather than treating either Illumos or ZoL as upstream?
I doubt there are enough developers who would want to work on ZFS generically
rather than ZFS in the context of a particular OS. ZoL maintains a clear
separation from Linux proper for licensing reasons so I'd think they're
"independent enough" to serve as upstream for non-Linux versions.

~~~
rbanffy
> ZoL maintains a clear separation from Linux proper for licensing reasons so
> I'd think they're "independent enough" to serve as upstream for non-Linux
> versions.

That would neatly solve the issue of ZoL patches never making it back to
Illumos.

------
ggm
As a long-time BSD user (since 1982) this both saddens and heartens me. It
saddens me, that the core development path in BSD was not able to sustain
being the "reference" model for a wider community. There is no point
pretending you can, when nobody else wants to follow that model.

The heartening moment, is that linux and BSD should share code when they can,
because its sensiblet to avoid pointless fork. Pointful fork, (and I exclude
licence terms mostly) is something we have to deal with. Pointless forking is
just a royal pain.

An outcome of this _should_ be that I get more guarantee a ZVOL export/import
cycle across Linux/BSD (which btw I have now done about 10 times on 10TB ZFS
filesystems) will work with no awkward binary consequence to flag/version
mismatch which came about because of two codebases: version mismatch because
one was "old" and one is "new" is a different thing.

~~~
gh02t
> It saddens me, that the core development path in BSD was not able to sustain
> being the "reference" model for a wider community.

Could you explain? FreeBSD was not the reference implementation of ZFS,
illumos was. ZoL is still tied up in the OpenZFS project (as are illumos and
FreeBSD), this is more a matter of rebasing onto the subproject where more
development is occurring. As it was, FreeBSD's implementation was already
using a Solaris/illumos compatibility shim, and it sounds like switching isn't
_that_ much work.

~~~
ggm
Oh, I misunderstood. I thought the input back into Linux ZFS grew out of the
(Free)BSD work. If its two independent OS trees both referring upstream to
Illumos, its a minor moment.

What does the solaris compatibility shim do in the end, which couldn't be done
direct in the codebase? I don't like shims, it feels like the linux
compatibility ABI moment where something gets added and the shim drifts, and
then you can't do eg DRI any more because "they changed how it worked and we
didn't catch up"

But, thanks for the cluestick hit. If this is just flavour of ice-cream from
the same truck, I'm less worried.

~~~
simcop2387
The shim, as I understand it, for linux is there to both handle some licensing
differences and to also translate between Linux's io subsystem which isn't
going to be turned into Solaris' nor will ZFS's be turned into Linux's IO
subsystem directly. They're basically compatible but have different ways of
doing things so it results in needing a shim to handle things.

------
adtac
Is there a resource that explains the historical intricacies and licensing
issues surrounding ZFS from the beginning? From what I've seen, it's a
clusterfuck whichever *nix OS you like.

~~~
chasil
As I understand it, including ZFS requires all linked code to be bound by the
CDDL, which the GPL cannot do.

[https://sfconservancy.org/blog/2016/feb/25/zfs-and-
linux/](https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/)

"[§]3.1 … Any Covered Software that You distribute or otherwise make available
in Executable form must also be made available in Source Code form and that
Source Code form must be distributed only under the terms of this License. …

"[§] 3.4 … You may not offer or impose any terms on any Covered Software in
Source Code form that alters or restricts the applicable version of this
License."

~~~
h1d
But Ubuntu figured it was ok to ship with zfs.

[https://blog.ubuntu.com/2016/02/18/zfs-licensing-and-
linux](https://blog.ubuntu.com/2016/02/18/zfs-licensing-and-linux)

Though FSF doesn't seem to support it.

[https://www.fsf.org/licensing/zfs-and-
linux](https://www.fsf.org/licensing/zfs-and-linux)

And a few HN posts regarding the Ubuntu's announcement.

[https://news.ycombinator.com/item?id=11125063](https://news.ycombinator.com/item?id=11125063)

[https://news.ycombinator.com/item?id=11240402](https://news.ycombinator.com/item?id=11240402)

~~~
BurningCycles
>But Ubuntu figured it was ok to ship with zfs.

Yes, but it's shipped as a separate kernel module (as in separate file) rather
than built into the Linux kernel. As for the legality of this, it can really
only be determined in court, which hopefully won't happen since I can't think
of anyone who would want to prevent Linux from using ZFS now that Sun is gone.

It would be great if it could eventually be part of Linux mainline which would
then allow it to easily be used on boot volumes as well. That would require
dual/relicensing though, since Linus Torvalds have said that CDDL code will
not be merged with mainline (most likey a result of consultation with Linux
Foundation lawyers).

~~~
riffraff
> I can't think of anyone who would want to prevent Linux from using ZFS now
> that Sun is gone.

Oracle? I doubt they would, but I mean, it's Oracle.

~~~
laumars
I get you point but Oracle don't really seem all that interested in maximizing
Solaris.

The problem we have is Oracle also don't seem at all interested in maximizing
ZFS either. So they'd quite happily see both die.

~~~
h1d
Only until they figure suing others would be worth a grab for them.

~~~
laumars
That doesn't contradict my statement.

One can be aggressively litigating using ones IP while also letting the
technology behind that IP die.

------
dpg23
I'll admit, I feel somewhat smug over this after being talked down to by BSD
guys. Regardless, I'm glad we can all enjoy a shared codebase for an amazing
filesystem.

------
davemtl
It's my understanding that code will not be committed into OpenZFS if it
cannot be compiled in both Linux and FreeBSD.

------
vermaden
TL;DR FreeBSD will rebase its ZFS code from Illumos to ZFS on Linux (ZoL).

~~~
carlavilla
If the ZFS FreeBSD code are going to be taken from ZoL, what's the difference
of use ZFS on FreeBSD and GNU/Linux?

~~~
chasil
FreeBSD can bundle it in the installer, and put the root filesystem in a ZFS
dataset.

Because of GPL incompatibility with the CDDL, Linux cannot do this. A
compliant installer must put root on something else, usually ext4 or xfs. A
Linux installer iso putting root in a zfs dataset opens a terrible legal door.

~~~
rleigh
Of course Linux can do this. I'm writing this very reply on a Linux system
booted directly off a ZFS dataset.

    
    
        % zfs list rpool/ROOT/default 
        NAME                 USED  AVAIL  REFER  MOUNTPOINT
        rpool/ROOT/default  14.8G  60.1G  11.9G  /
    

Support for this exists in GRUB and initramfs-tools, and it works perfectly.

The GPL is not an EULA. It's a distribution licence. There is absolutely no
problem in using ZFS on your system, and there's no legal restriction on what
an installer may or may not do.

------
jiveturkey
does this mean anything for mac?

~~~
h1d
Apple already has apfs.

~~~
zapzupnz
And? How's this relevant?

~~~
h1d
I mean, there's unlikely to be any official support of zfs on Mac and the fact
Apple developed apfs recently could mean there's less appetite for community
to port and support zfs on Mac.

~~~
xoa
> _could mean there 's less appetite for community to port and support zfs on
> Mac._

Eh? The community port and support already happened, _years ago_. I made the
move myself from ZEVO once Spotlight support got mainlined but even that was a
while ago and it already had a ton of great features before that. It is a
small scale effort compared to Linux _or_ FreeBSD of course, but it has kept
up pretty darn well and is pretty solidly developed at this point. I push it
pretty hard on my Macs and it's been pretty reliable, though there are
definitely edge case oddities that can be found. You can also see the smaller
scale of the effort in areas like the wiki not being fully up to date, or that
booting off of it still is rough. Even so it's pretty solid at this point and
hits all the core features including encryption.

Long term the big risk of course is that Apple will shut off all user low
level access to their drives via T-series chips in Macs, since they don't
actually give hardware owners the ability to use their own keys there. Ideally
this would be illegal but I doubt any movement will be made on that in the US
at least in the near future. Even so given that Apple up until recent has
still been selling brand new Macs without it macOS itself will likely support
running on those systems for a long time to come (Apple still officially
supports running the existing version even on 8 year old MPs, granted with
compromises but those had pretty fundamental divergences from modern firmware
too). O3X is still pretty nice in the mean time.

~~~
Hackbraten
I’m not terribly afraid of Apple doing that move. With Core Storage, Apple
already has abstracted away low level storage access years ago. Even if Core
Storage was mandatory (which it isn’t), O3X runs perfectly fine on top of Core
Storage either with or without ZFS encryption. O3X will continue to run
happily as long as block-level storage access remains built into macOS. And it
will because APFS is a very young filesystem, which depends on block-level
access; it took Apple a decade to build APFS from scratch so there’s no way
for Apple to get rid of this dependency without throwing APFS away and
starting from scratch.

But what if Apple simply built APFS into one of the next generations of
T-series chips so it can physically deny block-level access to software? Not
going to happen: Apple needs APFS to work not only with built-in storage but
also with external USB drives, RAM disks, DMGs, sparse bundles, and so on.
This means APFS needs to remain in kernel space, and kernel code will continue
to have block-level access, and so will O3X and all of its features.

------
kim0
Hope this puts to rest the claim that zfs on bsd is better maintained and
integrated than zol!

~~~
cat199
> and integrated

Considering one of thse comes default the base system and the installer can
install to it, has jail(8) integration, etc etc

and one of them is an addon which will never be merged to the main kernel
(which is only a kernel), and because of this, will likely never be directly
supported by the main linux distribution vendors, I'd say the jury is still
out on this piece..

lack of base system integration for linuces also leaves the 'maintained'
somewhat up in the air too.. if I'm running $linux_flavor and Zfs crashes, and
the ZoL devs blame this particular distros particular configuration/build
options, toolchain, etc where do I go for a fix?

migrate to another linux with totally different package mgmt, etc?

but yes, it looks like the zfs core code itself is more actively updated for
that portion directly.

~~~
e12e
> will likely never be directly supported by the main linux distribution
> vendors

Zfs is front and center for lxd on Ubuntu - and about as "supported" as can
be?

I just can't wait for crypto support to really land in open zfs - would make
it even easier to use for external drives (now encryption needs separate
support, geli on bsd, dm-crypt/luks on Linux). And using zfs as a volume
manager would make things in general easier and less complicated.

------
tiffanyh
DragonflyBSD Hammer2 filesystem all of a sudden looks way more appealing.

Kind of ironic given DragonflyBSD roots in FreeBSD

~~~
unmole
> DragonflyBSD Hammer2 filesystem all of a sudden looks way more appealing.

Why? Existing FreeBSD ZFS users can and in all probability will continue to
use it. Why does a less mature FS on a less widely used BSD derivative
suddenly look appealing to you?

