Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of ZFS in FreeBSD

lists.freebsd.org

Post reply on HN
Print view View original

51–60 of 102 posts

Re: The Future of ZFS in FreeBSD

#51

Post by Teknoman117 »

chasil wrote: post #21
carlavilla wrote: post #3

Earlier quoted context omitted.

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

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.

Uh, no?

If said installer downloaded and compiled the code (nvidia-drivers style), you'd not have an issue. Only once the code is combined does it "violate" the license. You can't distribute something in violation of GPL2, but you can keep it for yourself. As long as the installer doesn't distribute offending binaries, you're fine.

Re: The Future of ZFS in FreeBSD

#52

Post by simcop2387 »

ggm wrote: post #41
gh02t wrote: post #36

Earlier quoted context omitted.

> 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…

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…

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.

Re: The Future of ZFS in FreeBSD

#53

Post by xoa »

jiveturkey wrote: post #35

does this mean anything for mac?

According to Lundman earlier today [1] O3X ("OpenZFS For OS X") never fully made the transition from basing off of ZoL to illumos. So this won't really make a major practical difference for the Mac, O3X will just move fully back to basing off of ZoL and that'll be that. In terms of core feature set it's already doing pretty well, and has developed far farther then ZEVO ever could. If anything this might be good inasmuch as it'll mean ZoL specifically is getting another set of eyes towards maintaining portability, so perhaps long term both FreeBSD and O3X may benefit from a lot of extra eyes on it and a bigger userbase while not falling to too much Linux-specific behavior.

1: Issue #674

Re: The Future of ZFS in FreeBSD

#54

Post by jclulow »

loeg wrote: post #38
jclulow wrote: post #12

Earlier quoted context omitted.

I work at Joyent (one of the largest on-record commercial users of illumos today), and am a core member of the illumos community. While we will miss the Delphix folks, they were not driving the bulk of general work on illumos. I believe that comment by Matt/Kip reflects more of a personal opinion about how things should be (he's a stalwart FreeBSD contributor), rather than how they actually are in practice.

Huh, the rumors I've heard all say Joyent's use of illumos is not long for this earth.

I don't know what to tell you, except that people sometimes say things which aren't accurate when they believe it will advance their personal interests.

Re: The Future of ZFS in FreeBSD

#55

Post by zapzupnz »

h1d wrote: post #45
ggm wrote: post #24

Earlier quoted context omitted.

Definitely feels like it. OSX had its "we're onboard with ZFS" moment which vanished. I am believing this was a licence fubar.

Or they just figured they wanted a file system that also works on mobile devices (apfs even works on watchOS) with limited memory.

I could wear the ZFS thing was from so long ago that APFS wouldn't even have been a glimmer in an Apple engineer's eye. 10.5 or 10.6?

Re: The Future of ZFS in FreeBSD

#57

Post by jclulow »

loeg wrote: post #39
tivert wrote: post #6

> 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 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 f…

> 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…

> illumos' imminent death

Rumours of our death are, of course, greatly exaggerated.

Re: The Future of ZFS in FreeBSD

#58

Post by cyphar »

p_l wrote: post #33
chasil wrote: post #19

Earlier quoted context omitted.

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/ "[§]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 no…

It's the opposite way - GPL automatically covers the final product, and does not allow for licenses that have stronger terms than itself. CDDL is per-file license, does not automatically extend itself to the whole product. But it also has wording about patents et al, which puts it beyond direct inclusion in kernel just like MPL. Out of tree with one degree of separation (Solaris Porting Layer) is based on the precede…

> CDDL is per-file license, does not automatically extend itself to the whole product. But it also has wording about patents et al, which puts it beyond direct inclusion in kernel just like MPL.

Well, MPLv1 was incompatible with the GPL. MPLv2 has an explicit clause to make it compatible (namely to allow relicensing within limits). I would imagine the lack of "relicensing within limits" would be the key problem with CDDL and GPL -- since CDDL was based on MPLv1.

> Out of tree with one degree of separation (Solaris Porting Layer) is based on the precedent of AFS implementation for linux, where the argument was that the code is not derivative of Linux kernel code, as in no way was VFS unique to linux or any other crucial part involved.

Right, especially since the ZFS source code was developed completely separately to Linux and the SPL is licensed GPL+CDDL. This is the same thing that NVIDIA does with their drivers (they even build their driver binaries on FreeBSD to show that it "couldn't possibly" be a derived work of Linux and have a GPL shim).

Re: The Future of ZFS in FreeBSD

#59

Post by cyphar »

h1d wrote: post #42
chasil wrote: post #19

Earlier quoted context omitted.

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/ "[§]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 no…

But Ubuntu figured it was ok to ship with zfs. 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 And a few HN posts regarding the Ubuntu's announcement. https://news.ycombinator.com/item?id=11125063 https://news.ycombinator.com/item?id=11240402

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

Having spoken to some Canonical folks involved in this discussion, basically it boils down to the fact that the SPL (Solaris Porting Layer, which converts Linux VFS APIs to Solaris ones for ZFS) is GPL licensed and that ZFS was developed entirely separately from Linux (and Torvalds has said he agrees with the latter point). It also helps that ZFS is free software.

Honestly I think their strategy is that it's very unlikely they'll get sued (not to mention the past 5-8 years of OpenZFS development was done without an Oracle CLA). IMHO the FSF is primarily against it because they think it might water down the GPL's effects.

Re: The Future of ZFS in FreeBSD

#60

Post by rbanffy »

rincebrain wrote: post #15
rbanffy wrote: post #5

> 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?

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.

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?
Post reply on HN