Hacker News Reader

Comment by sandGorgon | Hacker News Reader

The most important line for me was "Today, you can run ZFS on Ubuntu 16.0.4.2 LTS with standard repositories and Canonical’s Ubuntu Advantage Advanced Support. That makes the decision easy."

Its highly interesting that Canonical does this with ZFS. I'm not sure why they dont market this more.

View on HN

I'm only a casual user of ZFS on Linux for personal storage projects, but I've spoken with people who rely very heavily on ZFS on Linux for their small businesses, and it's interesting to hear their perspectives on this. Essentially, because btrfs has failed to deliver on the next-gen filesystem front, ZFS on Linux is such a critical piece of technology that unless Red Hat has an answer soon for out-of-the-box ZFS on Linux, Canonical has a pretty staggering advantage. One theory is that Canonical has essentially forced Oracle to decide whether it wants to crack down on inclusion of CDDL-licensed code being shipped with Ubuntu's stock kernel, so Red Hat may be waiting to see if Oracle sweeps in or not before following suit.

I'd be very surprised if RHEL (by observing the progression of Fedora development) continues to bet on btrfs, as I have yet to encounter anyone (including myself) who would ever trust btrfs over ZFS on Linux with anything of importance based on their experiences with the two - my experience is anecdotal, but ZFS has been just as reliable on *BSD as with any Linux distribution.

btrfs is getting dropped from future versions of RHEL so you can see what Red Hat thinks of the future of btrfs.

RedHat is betting on xfs.

Red Hat has never spent any real resources on btrfs, they've been all about XFS when it comes to enterprise needs.

They employed one of the original Btrfs developers for the first half of its development, but not since 2012. I can't speak of their recruitment efforts, but it does seem all the Btrfs developers are happy at their respective companies; and the Red Hat file systems folks are happy working on what they're working on which is not Btrfs.

Oracle is not the one that could sue. There is nothing in the CDDL that prevents it being used else where.

The GPL on the other hand is a strong copy left. If you link against GPL code, your code must also be licensed as GPL.

This means the Linux copyright owners could sue the distributers of ZoL binaries, but Oracle could not.

Oracle has the power to allow their ZFS code to be relicensed as GPL, removing this road block, but they have no incentive to do so.

As I understand it, the license incompability between GPL and CDDL is that CDDL adds a restriction regarding patents, and GPL does not allow for additional restrictions to be added.

So to distribute CDDL licensed code is a breach of BOTH licenses as I see it, ignoring the 'patent peace' requirement of CDDL which would be the case if distributing it as GPL does not sound legal to me (IANAL).

I can certainly understand why Linus has stated that no CDDL code will be mainlined (brought into the Linux kernel tree), it all seems very ambiguous.

IANAL, but it (probably) depends on which license Canonical is using for the ZFS plugin.

If they use CDDL, then I can't see how Oracle would have a case.

They can't legally use anything except CDDL. If anyone could just pick and choose to alter the licensing, there wouldn't be any point in having licences.

According to the Software Freedom Conservancy

...redistributing a binary work incorporating CDDLv1'd and GPLv2'd copyrighted portions constitutes copyright infringement in both directions... [https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/]

so it seems that Oracle could in fact sue.

> so it seems that Oracle could in fact sue.

Says the SFC. But Oracle has had plenty of time and they have not sued. In fact, they have not criticized Canonical for integrating ZFS.

The past is not always a predictable measure for the future, especially as you don't know Oracle's agenda.

They might just wait until there is more money to be gained from a lawsuit or until there's more people already on ZFS who don't want to have anything less.

the courts will not allow that. you may claim that you recently discovered that there is infringement or you can claim that you are a new owner of a patent and are enforcing it.

But I dont think courts will take too kindly to someone who knowingly sat without doing something and waited for it to become big.

I would assume that Canonical has already sent infromation about this to Oracle. If they havent done anything now, they cant do anything later.

in fact - https://insights.ubuntu.com/2016/02/18/zfs-licensing-and-lin...

We at Canonical have conducted a legal review, including discussion with the industry’s leading software freedom legal counsel, of the licenses that apply to the Linux kernel and to ZFS.

And in doing so, we have concluded that we are acting within the rights granted and in compliance with their terms of both of those licenses

RedHat is apparently building something new called Stratis based on XFS, they're shooting for delivery within the next 1-2 years. Supposedly it'll be feature-equivalent to ZFS/Btrfs/LVM.

http://www.phoronix.com/scan.php?page=news_item&px=Stratis-R...

The ZFS comment in the document [1] is time inspecific. It's got version 1.0 in 1st half of 2018 and the "rough ZFS feature parity" comment is not until version 3.0, which has no listed time frame.

This is going to take lot of work, and not just for the stratis developers but for projects that need to manipulate it. It's asking for a lot of work for bootloader projects to support it, and

[1] https://stratis-storage.github.io/StratisSoftwareDesign.pdf

Filesystems are HARD, see the plethora of FS's on Linux that are dead, dying, or horribly engineered. This seems like such a monumental waste of resources, time, and energy to chase ZFS, which itself is not a stationary target. ZFS is constantly developing new features. I think a lack of ZFS in Linux is hurting it. And that wound will only deepen over time.

Well obviously Linux devs would love having ZFS in the kernel, Linus even half joked that he'd consider trying to relicense Linux to GPLv3 if it meant he could use ZFS and DTrace (this was back when Sun was considering GPLv3 as the license to use when going open source).

But the problem remains, CDDL and GPL are likely incompatible, and Linus has said that no CDDL licensed code will be merged, most likely per advice from lawyers.

So unless something drastically changes, ZFS is off the table, and thus work will continue on with alternatives, Stratis is one such alternative, bcachefs is another, and of course btrfs will not die just because Red Hat isn't supporting it anymore, as they barely did to begin with.

I'm friends with some of the original ZFS guys, Jeff Bonwick was a student of mine at Stanford and I got him to come to Sun, Bill Moore worked for me on BitKeeper. Those guys are seriously studly engineers. I've done file system work at Sun, I don't compare with Bill & Jeff, they are way better.

So yeah, trying to do better than those guys is going to be interesting. I'd like to know who is on the RedHat team working on this new file system, just the fact that they are trying is interesting.

Edit: and I was at SGI when XFS was pretty new, I know some of the XFS folks as well, Adam Sweeney and Mike Nishimoto.

I was the guy that plugged XFS into NFS over HIPPI, so I have more than a passing knowledge of it:

http://mcvoy.com/lm/bds.pdf

XFS was pretty cool but a lot of the technology that made it fast was XLV, the logical volume manager. XFS just made sure it handed very large, aligned, I/O requests to the volume manager, the volume manager was the layer that split them up and got all the DMA engines going. That's how we did 500MB/sec in the early 1990's on 200mhz MIPS chips, the MIPS chips weren't touching the data, the DMA engines were (the networking stack did page flipping to avoid bcopies).

I know XFS did other stuff for scaling but it most certainly did not do all the safety stuff (and I don't think it did transparent compression, those 200mhz MIPS cpus weren't fast enough to put that in there) that ZFS does.

So I'm wondering how much XFS has evolved from the SGI days. If it hasn't, I don't get why RedHat started there. Be really interested to know the back story.

XFS is the de facto standard file system for RHEL deployments, they employ a lot of engineers familiar with the code and it's the default since RHEL7 came out.

Do you know if they have any of the SGI team? Like Adam and/or Mike?

Eric Sandeen works for Red Hat on XFS, at the least. Mike and Adam are elsewhere according to their LinkedIn profiles - dunno who else was working on it at SGI.

    $ git log --since=”2016-01-01” --pretty=format:”%an” --no-merges -- fs/xfs | sort -u

https://pastebin.com/0Yv5giDK

XFS history https://lwn.net/Articles/638546/

Linux file systems, where did they come from? (Presented by Dave Chinner who has been XFS maintainer for a few years.) https://www.youtube.com/watch?v=SMcVdZk7wV8

>One theory is that Canonical has essentially forced Oracle to decide whether it wants to crack down on inclusion of CDDL-licensed code being shipped with Ubuntu's stock kernel

Huh? Are Canonical is shipping ZFS in their kernel now ? I thought they just distributed it as a separate module.

There was an article a bit ago on HN where the Free Software Conservancy (?) wrote that legally, shipping a precompiled binary kernel module is the same as having it in the kernel.

But obviously Canonical's lawyers don't think shipping it separately is the same as shipping it in the kernel, because if they did they would not ship it separately to begin with.

Granted. But Canonical's lawyers are not canonical.

There's legal disagreement, and saying "Ubuntu did it" doesn't make those problems disappear. (Sadly)

>>But Canonical's lawyers are not canonical.

Hmm... not sure what you meant by this statement ?

"authorized; recognized; accepted"

I.e. their opinion is not the only opinion on the matter.

I haven't seen any legal opinion since Canonical's press release, which states that they consulted with counsel who believed that they were in compliance with both licenses.

I -have- seen a lot of argument online, opinions and otherwise that disagree with this, but not anything from a lawyer - mainly "philosophical" or opining on the "intent" of the GPL, rather than "based on clauses x, y, and z, this is impermissible".

Which is not to say, if something of an opinion exists in response to Canonical's release of ZFS, I would love to see it - a legal opinion, not armchair lawyering or opinionizing.

The argument really is based around what constitutes a derivative work. ZFS does not depend on Linux, OpenZFS which ZFS on Linux derives from is an Illumos project first and foremost - does modifying it to plug into the Linux VFS layer make it a derived work of the Linux kernel?

If this ever goes to court it will be an interesting case.

SUSE has succeeded in shipping atomic OS updates and rollbacks by default both for enterprise and community versions of Linux several years ago. Facebook is using it, and the usage is growing. [1] And there are any number of examples of production usage of Btrfs at scale if you go look for them. [2] And the good and bad are fairly well understood, it is in fact getting better and will continue to get better.[3] And Red Hat isn't waiting. [4]

[1] https://www.spinics.net/lists/linux-btrfs/msg67885.html [2] https://www.spinics.net/lists/linux-btrfs/msg67308.html [3] https://www.spinics.net/lists/linux-btrfs/msg67940.html

[4] https://stratis-storage.github.io/StratisSoftwareDesign.pdf

What you're going to find in storage is that there are multiple valid approaches, no clear one size fits all winner, and people will choose based on the tools they're familiar with, the company they trust, and their use case. I pick Btrfs over ZFS pretty much based on equivalent trust and better flexibility for my use case, but then I'm much more familiar with Btrfs tools and where the bodies are buried than I am with ZFS. I don't need to go around impugning other projects to justify what I use.

Aren't Synology NAS devices also using Brtfs?

Yep, although they don't use Btrfs RAID but instead run it on top of LVM which provides the necessary RAID functionality.

Does LVM usage facilitates bitrot self-healing on btrfs part?

I have bet on ZFS for years in both business and my most important personal information and it has never let me down, on Illumos or Linux. Snapshots, upgrades, sync, and data transfer are just too easy to even consider switching. And support and features have seen steady improvements over the last decade. No other filesystem has all of these properties.

RHEL is not continuing to bet on btrfs; they are deprecating it: https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

As was explained in depth in the HN comments, Red Hat's decision to not provide enterprise support is based on the fact that they don't have the necessary engineers to backport and maintain one of the fastest moving pieces of code in Linux today. All of their btrfs engineers moved to Facebook, and they're still working on btrfs improvements.

There are many decisions involved in deciding what to provide enterprise support for, and whether you like it or not, technical merit is only one of many factors. So Red Hat's decision was likely not entirely based on technical merit.

SUSE still provides enterprise support for btrfs (like we've always done), and there's still plenty of work being done from various large contributors.

[I work at SUSE.]

    $ git log --since=”2016-01-01” --pretty=format:”%an” --no-merges -- fs/btrfs | sort -u

And then iterate for ext4 and xfs, and that comes to: 100 btrfs, 71 ext4, and 63 XFS contributors over those 18 months. They are all healthy ecofilesystems.

It sounds like you think you're disagreeing with me, but I'm not sure how that's possible given the near total lack of opinion in my post. In any case, the aspect of the parent comment that I was thinking of when I posted that was the part where the parent points out that Ubuntu has ZFS and how that could be a problem for RHEL. Yes RHEL offers a number of other FS options, but to my knowledge only ZFS and btrfs currently offer checksumming, which IMO is a big differentiator vs. more conventional filesystems.

I disagree with the use of the word "deprecating", and everyone has been parroting around the news as though Red Hat announced that btrfs causes machines to catch on fire.

Red Hat never provided enterprise support for btrfs, it was a technical preview that didn't pan out to become fully supported as part of their distribution. It's barely a story (there are plenty of other filesystems Red Hat doesn't support), but it's a good opportunity to spread misinformation.

> I disagree with the use of the word "deprecating"

Then you disagree (literally) with Red Hat's official statement as a matter of fact (not opinion). From Chapter 53, RHEL 7.4 release notes: "Btrfs has been deprecated ... Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux."[0]

Pretty definitive.

[0] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

The context that deprecated is used is "as a technical preview" which is different than saying that "in our opinion, btrfs is a deprecated technology and people shouldn't use it". So, while Red Hat did use that word, if you don't follow it up by explaining in what way support was deprecated then you're misleading people who aren't aware of the whole situation.

> One theory is that Canonical has essentially forced Oracle to decide whether it wants to crack down on inclusion of CDDL-licensed code being shipped with Ubuntu's stock kernel, so Red Hat may be waiting to see if Oracle sweeps in or not before following suit.

That is not a "theory" that anyone who understands the basics of the licenses adheres to. The possible threat is that linux' GPL could attack ZFS; not the other way round. There is nothing in the CDDL in the way of using ZFS in linux.

I'm not sure. Maybe it's because they're not really supporting it all that well. The hole_birth data loss bug is still not fixed in 16.04 LTS.

https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/160...

This is a major data loss issue with some workflows and it's pretty significant that Canonical hasn't backported it.

Reply on news.ycombinator.com