I'm interested in whether Oracle actual does have the rights to change the licence. They dissolved Sun as a legal entity but the CDDL licence is explicit about it being the legal entity that is Sun Microsystems Inc who is the only one who can change the licence.

Sun Microsystems, Inc. has not been dissolved. It was simply renamed "Oracle America, Inc."

One of the lawyers can probably weigh in more effectively than me, but generally a simple corporate name change would not abrogate a corporation's rights/obligations under a contract.

[...]If you are talking about ZFS, you're talking about the Oracle version. Do you think it has a lot of development going on? I don't know.

And if you're talking about OpenZFS, then yes, there's clearly maintenance there, but it has all the questions about what happens if Oracle ever decides - again - that "copyright" means something different than anybody else thinks it means.[...]

(The Linus quote has been trimmed to just the two paragraphs I'm responding to.)

The first paragraph is hugely, hugely, hugely disingenuous. If you're talking about ZFS, without explicitly stating which version of ZFS you're talking about, it's practically certain that you're talking about OpenZFS. Oracle ZFS is only available for Solaris, and you'll only be running Solaris if you aren't running it in a "production" environment; are willing to risk a visit by Oracle's lawyers (in fairness, for individuals that's a pretty low risk); or are paying Oracle a ridiculous sum of money for licensing and support. In the context of Linux and open source, I would bet a very large sum of money on a given unqualified reference to ZFS being to OpenZFS.

As for the copyright thing, as has already been posted in this thread, the CDDL is pretty darn explicit. Oracle has virtually no chance of prevailing if they decide they want to try to unilaterally change the terms.

I'm interested in whether Oracle actual does have the rights to change the licence. They dissolved Sun as a legal entity but the CDDL licence is explicit about it being the legal entity that is Sun Microsystems Inc who is the only one who can change the licence.

I am not a lawyer, but I can't imagine any court in the world having a problem with Oracle changing the license. The legal entity named may have been dissolved, but there is a very clear ownership chain from Sun to Oracle that means Oracle would be in the clear to make those changes.

> Please, Linus, stop being arrogant and ignorant, read this release note and tell> us why you think ZFS is more of a buzzword and has no real maintenance.

I'm talking about small details like the fact that Oracle owns the copyrights, but turned things closed-source, so the "other" ZFS project is a fork of an old code base.

If you are talking about ZFS, you're talking about the Oracle version. Do you think it has a lot of development going on? I don't know.

And if you're talking about OpenZFS, then yes, there's clearly maintenance there, but it has all the questions about what happens if Oracle ever decides - again - that "copyright" means something different than anybody else thinks it means.

> Not going out of your way to support ZFS is one thing. That we completely perfectly understand. Going out of> your way to deliberately break ZFS is another thing. The kernel developers are being assholes for doing that!

We didn't go out of our way to deliberately break anything.

But we do occasionally turn symbols that aren't meant to be used outside the kernel into GPL-only, because they have some internal implementation issues.

The fact is, the whole point of the GPL is that you're being "paid" in terms of tit-for-tat: we give source code to you for free, but we want source code improvements back. If you don't do that but instead say "I think this is _legal_, but I'm not going to help you" you certainly don't get any help from us.

So things that are outside the kernel tree simply do not matter to us. They get absolutely zero attention. We simply don't care. It's that simple.

And things that don't do that "give back" have no business talking about us being assholes when we don't care about them.

1. That's not a response to his comments about OpenZFS' technology or performance.

2. If exporting symbols for non-GPL open-source use "doesn't matter" and gets "zero attention" and the kernel maintainers "don't care" the change at issue would not have happened. The LKML thread makes super clear that Kroah-Hartman's (questionable) legal interpretations and personal dislike for Sun/Oracle played the dominant role...

... as they do in Linus' "response." No one is asking him to merge in OpenZFS - just not to intentionally and needlessly break it. This business about a potential Oracle copyright action has nothing to do with the kernel

There's a lot of technical information that goes over my head, but I don't understand all the people saying that Oracle might sue for using OpenZFS. ZFS isn't part of the Linux kernel so how would they sue exactly? The problem came in when the kernel developers stopped exposing a kernel flag to non-GPL code, correct? How would exposing that flag and allowing the OpenZFS project to access it create an in-road for an Oracle lawsuit? This seems less like avoiding litigation and more like the Linux kernel maintainers are petulantly kicking people out of their clubhouse.

There's some of each. The kernel symbol export was not a problem because Oracle might sue, and neither K-H nor Linus claimed that it was. Nerfing the export was a reasonably standard maintenance operation, basically "tidying up." (Although K-H's comments certainly cast it in a bad light, making it entirely possible to argue the real reason for doing so was bad faith.)

The "Oracle might sue" stuff is not in response to anything about the symbol, it's in response to the idea of integrating ZFS (which is licensed CDDL) into the Linux kernel (which is licensed GPLv2). The two licenses are both open source, but aren't strictly compatible with one another, opening up the possibility of a lawsuit if an organization distributes the two put together—though there's no possibility of a valid lawsuit purely from using them together, since neither the CDDL nor GPLv2 restrict usage rights. Their prohibitions only kick in on distribution (and even setting stuff up for all the employees within a company doesn't count as "distribution"; distribution only happens when software leaves an individual or corporate entity.)

If all that wasn't a complex pain-in-the-ass enough already... ZFS on Linux generally runs as a Linux kernel module, not inside the kernel—but many GPL partisans argue that that's already not kosher, since Stallman and the FSF have long taken the position that any code that links (in the C language sense) to other code is by definition "a derivative work." This idea falls flat on its ass logically, both because the Linux kernel has a specific interface for not-kernel code to link to it (ie, loadable kernel modules), and because in this particular case, ZFS can't possibly be "derivative" of the Linux kernel in any human normal sense, because it was originally developed under the Solaris operating system, and was not ported to Linux until many years later.

And as long as we're muddying the waters here... the kernel maintainers don't complain (much) about fully proprietary loadable kernel modules such as Nvidia proprietary graphics drivers, so it's a bit weird to get all up in arms about another open source project. And it's worth noting, Canonical has been shipping kernels with the ZFS headers statically built in (not on the other side of the LKM interface, and present whether you actually install ZFS or not) since 2016, with no lawsuit forthcoming.

It's not a simple topic.

See, this was my confusion. I understand that ZFS will never be a part of the Linux kernel short of a fire breaking out at the patent office and copyright law magically becoming logical overnight, but people seem to be taking the position that anyone was arguing that it should be mainlined.

K-H's comments made it sound like they were intentionally bricking ZFS out of spite. I'm not really sure how that's a defendable position, whereas the only defense I've been seeing on the forum is fussing about litigation or that ZFS isn't contributing to GPL licensed code so allowing it to continue using the kernel flag would be doing it some kind of favor.

My read of the situation is that K-H had a personal beef, Linus backed up that personal beef with technically inaccurate information to try to justify it, and all of this was done under the guise of kernel maintenance. It all seems a bit immature from the get-go, and anyone arguing about litigation is missing the entire point.

What K-H did was cleaning up of code. The flag is not used in the kernel and thus is removed to keep the code tidy. Everyone does that, or at least should be doing it.Part about ZFS came about as an answer to drama over ZFS actually using that flag and thus having to replicate functionality. While it was not a politically correct answer it fits with long-term kernel policy that anything that is not in the kernel is not considered when making kernel decisions and clean-up.

He and Linus are completely clear here even if they maybe didn't communicate in silk gloves. The licencing issues and oracle lawsuits are a completely different and unrelated matter. There Linus doesn't want to risk including ZFS into the kernel as he is afraid of Oracle. Considering that Oracle is involved in BTRFS development (GPL licence) instead of just licencing the OpenZFS (the original code from Sun that was forked) with GPL it does stink of usual Oracle fuckery.

Edit: "completely" to "completely different"

I may have misunderstood the situation but how would Oracle licence OpenZFS under the GPL when it's not their project and has already been released under CDDL? Surely the only thing they could licence would be a GPL version of Oracle ZFS and that still wouldn't change the legal status of OpenZFS would it?

Oracle bought Sun which had all the rights to the code that OpenZFS is built on. They could go out and say that they are licencing that code under GPL and solve all these problems. It's their code and they can licence it in any way they like. They can't, on paper, retroactively remove licence but they can still sue you and bankrupt you for several generations just to be dicks. Which is what Linus is afraid of.

Hypothetically, if Oracle were to have a sudden personality transplant and decided to release all Sun/Oracle ZFS versions up to and including the version that OpenZFS was forked from under a GPL-compatible licence, what would that mean for the OpenZFS project?

Would they be able to relicence the OpenZFS fork immediately? Or would they need to get permission from all the contributors, since the fork till now, to relicence their own contributions?

May I please see a link to the rapid asynchronous replication of lvm you're referring to? All I'm aware of is mirroring (which is not the same thing, for many reasons) and layering of DRBD with lvm (also mirroring, also not the same thing).

Hypothetically, if Oracle were to have a sudden personality transplant and decided to release all Sun/Oracle ZFS versions up to and including the version that OpenZFS was forked from under a GPL-compatible licence, what would that mean for the OpenZFS project?

Would they be able to relicence the OpenZFS fork immediately? Or would they need to get permission from all the contributors, since the fork till now, to relicence their own contributions?

The OpenZFS folks wouldn't even have a choice about it. CDDLv1 allows the license steward to offer additional versions of the license in the future. Oracle, having bought Sun, is the license steward. If Oracle adds an additional license version, any users of OpenZFS have the option of using either the original CDDLv1, or the new version.

Note that this doesn't effectively give Oracle the ability to add further restrictions to the code, because if they said "CDDL2 means FU, you can't use it" users would still have the right to choose the original CDDLv1 license. But it does give them the opportunity to, eg, release a CDDL2 that's weak permissive enough to be GPL compatible.

I'm interested in whether Oracle actual does have the rights to change the licence. They dissolved Sun as a legal entity but the CDDL licence is explicit about it being the legal entity that is Sun Microsystems Inc who is the only one who can change the licence.

Oracle bought Sun Microsystems lock, stock, and barrel including all intellectual property. They are the license steward for ZFS and Dtrace, as well as any and all other intellectual property owned by Sun at the time of the sale.

2. If exporting symbols for non-GPL open-source use "doesn't matter" and gets "zero attention" and the kernel maintainers "don't care" the change at issue would not have happened. The LKML thread makes super clear that Kroah-Hartman's (questionable) legal interpretations and personal dislike for Sun/Oracle played the dominant role...

... as they do in Linus' "response." No one is asking him to merge in OpenZFS - just not to intentionally and needlessly break it. This business about a potential Oracle copyright action has nothing to do with the kernel

In fairness to Linus and Kroah-Hartman, if the symbol export in question was no longer being used by any driver in the kernel tree, cleaning up the tree (by removing that export) was a reasonable thing to do. Leaving disused interfaces lying around is a great way to end up with some interesting cases of bitrot in the source tree. They don't - can't! - know offhand whether or not a given interface is being used outside the main kernel tree, and since they don't make explicit guarantees about the kernel interfaces being stable for device drivers, they're free to change whatever they want. (Which in itself is something I view as undesirable, but that's a different discussion to what this article is about.)

I'm willing to give them the (well, okay, some) benefit of the doubt here; I don't think it was a deliberate decision to break ZFS on Linux. That said, I do think that they're being needlessly antagonistic in their responses to those asking about ZFS having been broken. Those responses are a perfect demonstration of the sort of things I was thinking about when I decided to install FreeBSD, instead of Linux, for running ZFS - and they really aren't doing anything to change my mind in that regard. Which, sure, isn't going to change their views. I don't expect it to. I'm simply saying that, based upon the attitudes that seem to be endemic within the Linux community, I would view ZFS on Linux to be at best a second tier platform, whereas on FreeBSD it's a first tier platform.

No one who cares about open source should use anything from Oracle... ever.

ZFS is not "from Oracle"—at least, the ZFS you can get in Linux or FreeBSD is not.

ZFS was originally developed at Sun Microsystems. When Oracle bought Sun, most of the original ZFS developers insta-quit in protest, and forked the original Sun ZFS project as OpenZFS. OpenZFS has been under independent development for nearly a decade.

Oracle has also continued developing their own version of ZFS, and the two (Oracle ZFS and OpenZFS) have diverged signficantly, as Oracle's goals and the OpenZFS team's goals are themselves pretty divergent.

TL;DR running OpenZFS != using anything "from Oracle."

Kind of. ZFS (in general) still originates with Sun, and I wouldn't be surprised if Oracle has an ownership stake on at least some of the IP there, including the trademark and several patents. They also have effective control over the license for the project, since the current license explicitly states that Sun (ie. Oracle) has an exclusive right to provide new licenses for the project.

It might be that they still wouldn't have a leg to stand on, but that's never stopped Oracle from sending legal threats and filing lawsuits before.

> Please, Linus, stop being arrogant and ignorant, read this release note and tell> us why you think ZFS is more of a buzzword and has no real maintenance.

I'm talking about small details like the fact that Oracle owns the copyrights, but turned things closed-source, so the "other" ZFS project is a fork of an old code base.

If you are talking about ZFS, you're talking about the Oracle version. Do you think it has a lot of development going on? I don't know.

And if you're talking about OpenZFS, then yes, there's clearly maintenance there, but it has all the questions about what happens if Oracle ever decides - again - that "copyright" means something different than anybody else thinks it means.

> Not going out of your way to support ZFS is one thing. That we completely perfectly understand. Going out of> your way to deliberately break ZFS is another thing. The kernel developers are being assholes for doing that!

We didn't go out of our way to deliberately break anything.

But we do occasionally turn symbols that aren't meant to be used outside the kernel into GPL-only, because they have some internal implementation issues.

The fact is, the whole point of the GPL is that you're being "paid" in terms of tit-for-tat: we give source code to you for free, but we want source code improvements back. If you don't do that but instead say "I think this is _legal_, but I'm not going to help you" you certainly don't get any help from us.

So things that are outside the kernel tree simply do not matter to us. They get absolutely zero attention. We simply don't care. It's that simple.

And things that don't do that "give back" have no business talking about us being assholes when we don't care about them.

Thank you for this; it makes the issues way clearer. Given all the billion-dollar hooha between Oracle & Google, I can totally see why Linus has taken this stance.

> Not going out of your way to support ZFS is one thing. That we completely perfectly understand. Going out of> your way to deliberately break ZFS is another thing. The kernel developers are being assholes for doing that!

We didn't go out of our way to deliberately break anything.

But we do occasionally turn symbols that aren't meant to be used outside the kernel into GPL-only, because they have some internal implementation issues.

The fact is, the whole point of the GPL is that you're being "paid" in terms of tit-for-tat: we give source code to you for free, but we want source code improvements back. If you don't do that but instead say "I think this is _legal_, but I'm not going to help you" you certainly don't get any help from us.

So things that are outside the kernel tree simply do not matter to us. They get absolutely zero attention. We simply don't care. It's that simple.

And things that don't do that "give back" have no business talking about us being assholes when we don't care about them.

This is disingenuous at best and most reasonably outright lying. When you namecheck a specific project you “don’t care about”, you actually do care. He should be smarter enough to stop digging.

Torvalds isn't a native English speaker. He means "don't care about" in the technical sense that it's stuff that is not relevant to the kernel. Clearly, it's something that he does care about on a personal / political level.

As for alternatives, it's a shame that Ceph is such a pain to setup on a single host. It does have the feature set folks are looking for in terms of a dynamic, checksumming 'raid' implementation. But since it's designed to be distributed across multiple hosts, by default it's way overkill for the home nas use case.

It's actually not that difficult - and the next version coming this spring will have really robust simplified management functionality, most of it even available from the inbuilt web dashboard.

If Oracle wins it's Java case in a final judgement against Google, Oracle will be motivated to find other suits. If ZFS Linux becomes widespread among consultants and users with deep pockets, then surely Oracle would sue for infraction.

If Oracle wins it's Java case in a final judgement against Google, Oracle will be motivated to find other suits. If ZFS Linux becomes widespread among consultants and users with deep pockets, then surely Oracle would sue for infraction.

As has already been pointed out, users aren't in violation - their protection via the CDDL is as iron clad as anything ever can be. But distributors that bundle ZFS may be violating the CDDL, or the GPL, or possibly both.

Even a letter from Oracle wouldn't help. Sun released ZFS to the community and began taking contributions long before Oracle bought Sun. Then Oracle stopped contributing code to the community and what's now ZFS on Oracle Solaris is not compatible with OpenZFS projects like ZFS on Linux.

I think Sun was taking copyright assignment from contributors, so Oracle could relicense the Oracle ZFS code, but it wouldn't help much. The community would have to either throw away the existing MacOS, Linux, and BSD Unix ports or just ignore the new Oracle code. The community has a ton of improvements (such as sequential scrubs/resilver, which is a huge performance boost).

If Oracle made a new version of CDDL, it would apply to all such subsequent developments unless their authors explicitly prohibited that (see 4.2 in CDDLv1). So a new, GPL-compliant version of CDDL probably would fix the problem to a large extent (I don't know how many code authors have made such a prohibition).

Quote:

Quote:

And the Mac and BSD guys don't even want a GPL'd ZFS as that is a worse license for them. CDDL is limited by the file boundary so it's not a problem to include in a BSD kernel. So a GPL'd ZFS might just split the community into 2 separate code bases.

Yes, it might. Although a new version of CDDL could be more permissive than GPL while still being compatible with it, I'm doubtful whether any such solution could prevent a split anyway.

No one who cares about open source should use anything from Oracle... ever.

Unfortunately for that idea, ZFS is one of the closest things to magic you can get as a sysadmin.

This is the main problem. BTRFS is an unstable joke that is at best on testing stage and no sane person would store actual data on it.

There is no replacement for ZFS. It's orders of magnitude in-front of any other FS available.

Edit: "a unstable" to "an unstable"

I don't understand why it seems like Btrfs is stuck in perpetual beta state? People have been saying it's not ready for production for like 7 years. Why doesn't Btrfs ever get these issues sorted and get to a ready-for production state?

Is there insufficient interest by developers to work on Btrfs? Is there insufficient interest by corporate sponsors like Red Hat, IBM, et al, who contribute developer resources to some free software projects, but just don't care about Btrfs?

I mean, it depends what you're using it for, and how you consider such things. And I suspect that to some degree, "BTRFS isn't ready" has just gotten stuck in public consciousness and would be the talking point going around regardless of any underlying technical changes.

Purely anecdotally, I've been running BTRFS in production for over 5 years now without any problems (well, without any problems at the filesystem level at least; some of the drives have physically failed!).

Btrfs is fine on a single drive, particularly without too many snapshots, without inline compression, and without messing up and getting it extremely full.

Btrfs is typically okay on a small btrfs-raid1 or btrfs-raid10 array lightly loaded, eg with a single user (even if that single user is occasionally spinning up VMs or something).

Btrfs falls over all too easily on a btrfs-raid1 or btrfs-raid10 array with moderate to heavy load (eg, 10+ users accessing VMs or databases). It also does not handle drive failures at all gracefully, refusing to boot from degraded btrfs-raid1 or btrfs-raid10 arrays, not wanting to mount them read-write, and tending to permanently hose them up if forced to mount a degraded array read-write (which SHOULD be fine).

There are also serious problems with replication that I don't think have been fixed yet, in particular, a crashed replication attempt will leave a "partial snapshot" in place and browseable on the target, both breaking further attempts to replicate and severely screwing things up for normal access on the target (resulting in hard I/O errors) unless and until the offending "partial" snapshot is sleuthed out and manually destroyed by an admin. There is no easy way to detect a partial snapshot, either—you just have to traverse the system looking for I/O errors on read.

I got very, very annoyed in short order with the btrfs-dev mailing list casually tossing off those and similar problems as "what do you expect, it's beta" (which it has not been for many years), or just general uninterest in reliability issues in replication or multi-disk arrays, uninterest in the drastic difference between a normal admin expectation of a redundant array (mount functional and automatic if degraded), etc, etc, etc.

Jim, why is your bar business/enterprise use cases when your readership (and content) here is predominantly home use situations anyway? It is exceedingly rare that a home user would run a heavy VM or DB workload that would tip over btrfs. The average home user running a fileserver or home server should prioritize backups over raid anyway and benefits greatly from btrfs's flexibility. But if bitrot protection or snapshots are desired, it is hard to see where btrfs's raid implementation fails the home use case. The fact that btrfs has use cases that it isn't suitable for does not make it bad or less useful for the use cases that it is suitable for. I also think it is a little unfair to ridicule the btrfs-dev mailing list when we HAVE seen substantial fixes, including to parity raid, compression, and quotas.

Software developer in not recommending product with license that is incompatible with his own stuff total fucking non-shocker, the most obvious thing in the world, utterly fascinated why Jim Salter would not see this one coming... @_@

No one who cares about open source should use anything from Oracle... ever.

ZFS is not "from Oracle"—at least, the ZFS you can get in Linux or FreeBSD is not.

ZFS was originally developed at Sun Microsystems. When Oracle bought Sun, most of the original ZFS developers insta-quit in protest, and forked the original Sun ZFS project as OpenZFS. OpenZFS has been under independent development for nearly a decade.

Oracle has also continued developing their own version of ZFS, and the two (Oracle ZFS and OpenZFS) have diverged signficantly, as Oracle's goals and the OpenZFS team's goals are themselves pretty divergent.

TL;DR running OpenZFS != using anything "from Oracle."

If they forked AFTER Oracle purchased Sun can you be positive that the fork will withstand a lawsuit?

The entire point of open source licenses—including but not limited to the CDDL—is to grant users and developers rights that cannot later be taken away. Really, the entire point of all written licenses is to grant usage, development, and/or distribution rights that cannot be removed or altered arbitrarily.

Distributing any code developed at Oracle after they changed license to proprietary would absolutely, 100% get your ass sued. But once you've granted perpetual rights to users and devs via a license, while you can change that license going forward, you can't retroactively take it away from users of the original codebase prior to the change.

ZFS was licensed CDDL by Sun Microsystems; when Oracle purchased Sun, they were within their rights as owners to change their own distribution policy going forward, but that does not affect the rights already granted either to existing users and devs, or to new users and devs who receive distributions of that codebase from existing users and devs, whose rights were not and could not be revoked (under the terms of the license itself). Further, the new recipients get the same rights, and for the same reasons.

This all makes perfect sense, but the problem is that we all used to feel the same way about APIs not being copyrightable, & look how that's going right now. As stupid as it seems to have to worry about idiotic lawsuits, SCO & Oracle have forced the FOSS community to be paranoid about them.

Even a letter from Oracle wouldn't help. Sun released ZFS to the community and began taking contributions long before Oracle bought Sun. Then Oracle stopped contributing code to the community and what's now ZFS on Oracle Solaris is not compatible with OpenZFS projects like ZFS on Linux.

I think Sun was taking copyright assignment from contributors, so Oracle could relicense the Oracle ZFS code, but it wouldn't help much. The community would have to either throw away the existing MacOS, Linux, and BSD Unix ports or just ignore the new Oracle code. The community has a ton of improvements (such as sequential scrubs/resilver, which is a huge performance boost).

If Oracle made a new version of CDDL, it would apply to all such subsequent developments unless their authors explicitly prohibited that (see 4.2 in CDDLv1). So a new, GPL-compliant version of CDDL probably would fix the problem to a large extent (I don't know how many code authors have made such a prohibition).

Quote:

Quote:

And the Mac and BSD guys don't even want a GPL'd ZFS as that is a worse license for them. CDDL is limited by the file boundary so it's not a problem to include in a BSD kernel. So a GPL'd ZFS might just split the community into 2 separate code bases.

Yes, it might. Although a new version of CDDL could be more permissive than GPL while still being compatible with it, I'm doubtful whether any such solution could prevent a split anyway.

Code Authors (termed Contributors in the license) don't get to opt out of future licenses.Initial Developers do, where the Initial Developer is the person who originated the project and put it under CDDL in the first place. So in the case of OpenZFS that's Sun is it not?

So Oracle can make ZFS compatible with the GPL any time they want, not just to a large extent - but entirely.

"As aggressive as OpenZFS users and developers might find Kroah-Hartman's language around removing the export of kernel symbols, the actual change was well within Linux kernel policy. And there's nothing wrong with Torvalds supporting either Kroah-Hartman's action or the policies it followed."

Well, OK.

But I think intent matters.

I think the intent was to follow the long-existing policy of tidying up the code by removing interfaces that were no longer needed by other GPL'ed and integrated into the kernel repository code. However, as an added bonus, KH could take a swipe at (open)ZFS.

Jim, why is your bar business/enterprise use cases when your readership (and content) here is predominantly home use situations anyway? It is exceedingly rare that a home user would run a heavy VM or DB workload that would tip over btrfs. The average home user running a fileserver or home server should prioritize backups over raid anyway and benefits greatly from btrfs's flexibility. But if bitrot protection or snapshots are desired, it is hard to see where btrfs's raid implementation fails the home use case. The fact that btrfs has use cases that it isn't suitable for does not make it bad or less useful for the use cases that it is suitable for. I also think it is a little unfair to ridicule the btrfs-dev mailing list when we HAVE seen substantial fixes, including to parity raid, compression, and quotas.

I remember arguing awhile back that if btrfs wasn't ready yet, it was never going to be done, that it had fundamental architectural mistakes that were unfixable, at least by mere mortals.

I had that argument more than five years ago, and it's still not done.

Trusting btrfs at this point strikes me as foolish. Stick with something that works. Ext4 isn't especially featureful in and of itself, and is vulnerable to hardware failure, but on a software level it's excellent. It can be mixed it with mdraid and LVM to give it parity and hotswap volume support.... not as good as ZFS's, but a lot better than nothing. Unless you buy an appliance, managing this stack takes technical skill, but it won't corrupt data on good hardware. (ZFS may not corrupt data even on bad hardware, which is why it's attractive.)

Particularly with backups, this is critical. If anything in your home (or enterprise, for that matter) needs to absolutely work, every single time, it's the backups.

I haven't used ZFS on Linux, but I haven't really heard any horror stories about it, either. I have heard about remarkable amounts of data loss attributed to btrfs filesystems. This is purely anecdotal, but since pissed-off people tend to talk about problems, if ZFS (or ext4) had really serious issues, I think we'd probably know about them. I definitely do know about lots of problems with btrfs, including at least one person claiming to have lost data right here in this very thread.

Your recommendation strikes me as a very bad one. btrfs may not have bitten you yet, but any filesystem that falls over as soon as you challenge it is not a filesystem to recommend to anyone, for any purpose, because usage patterns change over time.

Most, if not all of the features listed can be achieved with existing Linux features, in any case, whether you use btrfs or not:

Atomic snapshots: lvm or dm-thinBlock-level checksums: dm-integrityRapid replication: lvmThe only debatable one is tansparent compression, but file systems other than btrfs do offer it iirc

ZFS' biggest features that are not so simple to do with vanilla linux are zraid and block-level deduplication, but they're admittedly more niche features too.

These don't really seem like direct replacements; data integrity is probably the most important feature of ZFS, but dm-integrity, while nice in theory, is a bit awkward as a bolt-on module. Unless I've misunderstood, it also uses journalling for its atomicity which has performance implications (and the alternative bitmap mode is potentially unreliable which kind of defeats the entire point).

LVM snapshots are nice, but unless something's changed since the last time I looked at them, they have no equivalent to ZFS send, which is another big feature of ZFS that I love, as it allows for very efficient backups to another array or system. Local snapshots are great for short-term recovery, but you shouldn't really rely on them as backups.

Also not sure I would dismiss zraid; if you're building for capacity rather than performance then it's the best way to do-so. It's ideal for a backup array that you'll be zfs sending to, provided you've got enough parity drives to account for errors (I think you want to be running at least zraid-2 these days).

Now that OpenZFS' encryption support seems complete, I can't think of any reason I wouldn't just use it on all Linux systems going forward

I support the idea of BTRFS, but like others I have my concerns about reliability, while ZFS is very much battle tested. The only feature it had that ZFS lacked (but maybe doesn't anymore, been a while since I looked into it) were ref-links; technically ZFS has always supported these, but they were never exposed to cp or similar tools as something users could use, they were just used to implement other features (including de-duplication).

I tried using btrfs for a while and, compared to ZFS, it's quite far behind in capability and speed and I had a ton of problems with recovery when one of my drives failed in my RAID10 equivalent. ZFS has been faster, more stable, more flexible, and while I haven't yet had a drive failure, it seems to have a clear recovery path should one exist.

Linus' comments disappoint me considerably. I don't like ZFS has an incompatible license but ultimately it's still open source and it works better than btrfs and the important of my data eclipses these sorts of gripes. It's not great for every purpose, when it works pretty damn well for on my NAS.

I'm definitely not on team Linus on this one. Saying something is bad but having no alternative solution makes for a pretty empty case.

The only legitimate reason to not use ZFS is cost. Memory needs to be scaled up with storage (aka RAM on the controller/NAS/hardware). Otherwise, ZFS was the promised land of storing data, accessing it faster, more scalable, and more reliable. Yes?

I am by no means an expert on ZFS, however my understanding - barring two specific use-case caveats - is that ZFS needing a lot of RAM is a furphy. It doesn't need a lot of RAM or to scale it up as storage expands. You can happily run a 20TB ZFS filesystem in 4GB (even 2GB) of RAM. The specific caveats I'm aware of are:

1) Deduplication. If you enable the optional dedupe feature, you need more RAM. This is because with dedupe, you need to compare new write-data requests with what you already have in the filesystem to determine if you already have a copy or not. Therefore for any sort of reasonable performance in the comparison process, you need to keep the hashtable of all written blocks in memory so that the comparison between the hash of the new data to be written vs all the other hashes of existing data can be done without having to go out to disk to retrieve those millions (in larger filesystems) of hashes. I also suspect that it helps to be able to cache the write-data in memory for longer before writing to disk to allow this comparison to happen without creating spurious 'temporary' writes of data you might end up discarding (because you already have a copy) anyway.

2) Heavily utilised random I/O access patterns. If you are using the fileserver as a workgroup (or larger) fileserver to service lots of small I/O requests, for example, you want as big a RAM cache as practical to try and serve as many of those requests from the cache without going back to disk as possible. The article referred to this already in its discussion of the ARC - ZFS's name for its RAM cache. For example, if you have home drives/windows profiles for an office of 10 people being mounted from the fileserver, you'll want fast random I/O access to that large number of frequently accessed small files, application configs, copies of the windows user registry, user documents, profile scripts (.bashrc etc.).

If you have a 20TB media server for example (I have no idea who would have such a thing!), that tends to mainly store multi-gigabyte sequential video files that are streamed sequentially from it, then you don't need a huge ARC, as a single video file would probably consume any practicle ARC by itself anyway (e.g. a 50GB 4k 2 hour long video file).

If Oracle wins it's Java case in a final judgement against Google, Oracle will be motivated to find other suits. If ZFS Linux becomes widespread among consultants and users with deep pockets, then surely Oracle would sue for infraction.

Big companies are often involved in numerous legal disputes at any one time. I can't imagine Oracle would wait to see what happened in their suit against Google before going after people for using ZFS with Linux if they thought they had a good case and an opportunity to make money. The company employs 136,000 people and the way they behave sometimes you would think 135,000 of them must be lawyers!

The only time I could see them waiting would be if they needed the Google case to establish a particular legal precedent in advance of any action over ZFS.

I'm interested in whether Oracle actual does have the rights to change the licence. They dissolved Sun as a legal entity but the CDDL licence is explicit about it being the legal entity that is Sun Microsystems Inc who is the only one who can change the licence.

I am not a lawyer, but I can't imagine any court in the world having a problem with Oracle changing the license. The legal entity named may have been dissolved, but there is a very clear ownership chain from Sun to Oracle that means Oracle would be in the clear to make those changes.

This is what I'm wondering, if someone knows otherwise who worked at Sun. Whether there was a conscious reason for the licence not making provision for a party other than Sun in case of a sale of the company's assets.

I'm not a lawyer either, but someone seems to have had a specific aim when they started out with the open source licensing wording.

I wish more people would jump ship to BSD. It's run by mostly reasonable humans who don't break entire projects by spite-committing their own political bullshit in to the kernel. I've said for years Linux is more of a side show than a real OS kernel, yet somehow it's become the defacto standard. I personally run all my servers on OpenBSD and I couldn't be happier. I can do everything anyone can do on Linux, have a better security and patch schedule, better asynchronous I/O stack (kqueue >>>> epoll) and BSD kernel dev isn't run by a bunch of ideologues who stick their foot in their mouth constantly. The license is also infinitely better for people who want to get actual work done and aren't trying to push an ideology.

Then why is it that (as per top500.org, November 2019 list) 100% of the top 500 supercomputers currently operating run Linux? Surely it has got something right - if BSD were so technically superior, the number crunchers would jump ship even at minute advantages, they add up quite quickly.

Also - OpenBSD, not run by a bunch of ideologues - have you heard of Theo de Raadt?

Jim, why is your bar business/enterprise use cases when your readership (and content) here is predominantly home use situations anyway? It is exceedingly rare that a home user would run a heavy VM or DB workload that would tip over btrfs. The average home user running a fileserver or home server should prioritize backups over raid anyway and benefits greatly from btrfs's flexibility. But if bitrot protection or snapshots are desired, it is hard to see where btrfs's raid implementation fails the home use case. The fact that btrfs has use cases that it isn't suitable for does not make it bad or less useful for the use cases that it is suitable for. I also think it is a little unfair to ridicule the btrfs-dev mailing list when we HAVE seen substantial fixes, including to parity raid, compression, and quotas.

I remember arguing awhile back that if btrfs wasn't ready yet, it was never going to be done, that it had fundamental architectural mistakes that were unfixable, at least by mere mortals.

I had that argument more than five years ago, and it's still not done.

Trusting btrfs at this point strikes me as foolish. Stick with something that works. Ext4 isn't especially featureful in and of itself, and is vulnerable to hardware failure, but on a software level it's excellent. It can be mixed it with mdraid and LVM to give it parity and hotswap volume support.... not as good as ZFS's, but a lot better than nothing. Unless you buy an appliance, managing this stack takes technical skill, but it won't corrupt data on good hardware. (ZFS may not corrupt data even on bad hardware, which is why it's attractive.)

Particularly with backups, this is critical. If anything in your home (or enterprise, for that matter) needs to absolutely work, every single time, it's the backups.

I haven't used ZFS on Linux, but I haven't really heard any horror stories about it, either. I have heard about remarkable amounts of data loss attributed to btrfs filesystems. This is purely anecdotal, but since pissed-off people tend to talk about problems, if ZFS (or ext4) had really serious issues, I think we'd probably know about them. I definitely do know about lots of problems with btrfs, including at least one person claiming to have lost data right here in this very thread.

Your recommendation strikes me as a very bad one. btrfs may not have bitten you yet, but any filesystem that falls over as soon as you challenge it is not a filesystem to recommend to anyone, for any purpose, because usage patterns change over time.

It doesn't sound like you use btrfs and certainly haven't paid attention to the change log. Why does something you said 5 years ago have relevance to a codebase today that has seen thousands of commits and hundreds of thousands of lines of code added or changed? Synology has allowed btrfs on md arrays for over two years now. OpenSUSE has single btrfs as the default to run snapper. Wouldn't the world have come crumbling down if btrfs was as unreliable as you're suggesting? I have been running a btrfs raid1 array for two years without issue, including with low load databases, virtual matchines, LXC containers, snapshots, etc. I've also been running single devices as my / on OpenSUSE for a year or so, again no issue.

Also, I didn't recommend btrfs so I don't know where you go that from. I said home users are better off making backups than a raid array, and that complaining that btrfs raid isn't suitable or well adapted to high intensity workloads isn't applicable to the target audience of this article.

Be careful not to take "requirements" listed at the FreeNAS forums as gospel. They're first of all intended for FreeNAS *specifically*, not for ZFS itself, and second not always grounded adequately in reality and accuracy.

I'd say you should take the FreeNAS forums as a literal gospel, stuff like their insistence that anybody who does not accept our Lord and Saviour ECC will be doomed to eternal damnation by the "scrub of death" (hint, that's not how checksums work) has a certain hint of religious fervor to it

After reading the first paragraph, I can't stop picturing Linus using "Supreme Maintainer" as a custom title on all Linux discussion boards.

Linus Torvalds of House Suomi, A Coder of His Name, King of the Distros and the First Kernal, Protector of the Seven Forks, the Father of Linix, the Supreme Maintainer of the Core, the Sisu, the Breaker of Closed Source

Jim, why is your bar business/enterprise use cases when your readership (and content) here is predominantly home use situations anyway? It is exceedingly rare that a home user would run a heavy VM or DB workload that would tip over btrfs. The average home user running a fileserver or home server should prioritize backups over raid anyway and benefits greatly from btrfs's flexibility. But if bitrot protection or snapshots are desired, it is hard to see where btrfs's raid implementation fails the home use case. The fact that btrfs has use cases that it isn't suitable for does not make it bad or less useful for the use cases that it is suitable for. I also think it is a little unfair to ridicule the btrfs-dev mailing list when we HAVE seen substantial fixes, including to parity raid, compression, and quotas.

I think you're seriously misguided here. for one, I'd wager you vastly underestimate the size of Ars's audience who work or are experienced in the professional/enterprise space.

Second, I highly doubt the "average home user" is running a file server. home users running a file server have to be a tiny, tiny sliver of the user base, and are likely to be pro/enterprise people using what they're familiar with in their work. FAT would likely suffice for the vast majority of home users if it wasn't for the addressing limitations.

from being forcibly published in the event of a GPL enforcement lawsuit victory.

This isn't even a possibility and the idea was created as anti-GPL fud. Copyright disputes do not force release of other copyrighted works.

The concern isn't due to copyright, it's due to the GPL being a Viral License. The concern <FUD> under the GPL. I'm not aware of this having been tested in court, but <FUD> there.

That tired old line was one of the many tools Microsoft attempted. Didnt work for them either. If you put gpled code into proprietary binaries without releasing source code what happens is a copyright infringement suit and damages if found to be infringing the copyright of the gpled code (if you don't respond to the formal warning and timelimits within beforehand) .

I wish more people would jump ship to BSD. It's run by mostly reasonable humans who don't break entire projects by spite-committing their own political bullshit in to the kernel. I've said for years Linux is more of a side show than a real OS kernel, yet somehow it's become the defacto standard. I personally run all my servers on OpenBSD and I couldn't be happier. I can do everything anyone can do on Linux, have a better security and patch schedule, better asynchronous I/O stack (kqueue >>>> epoll) and BSD kernel dev isn't run by a bunch of ideologues who stick their foot in their mouth constantly. The license is also infinitely better for people who want to get actual work done and aren't trying to push an ideology.

Then why is it that (as per top500.org, November 2019 list) 100% of the top 500 supercomputers currently operating run Linux? Surely it has got something right - if BSD were so technically superior, the number crunchers would jump ship even at minute advantages, they add up quite quickly.

Also - OpenBSD, not run by a bunch of ideologues - have you heard of Theo de Raadt?

I dunno, why is so much simulation on those supercomputers done in Fortran, a language which is effectively dead in every other context? It's almost like supercomputers have very specific needs and their needs don't generalize well...

from being forcibly published in the event of a GPL enforcement lawsuit victory.

This isn't even a possibility and the idea was created as anti-GPL fud. Copyright disputes do not force release of other copyrighted works.

The concern isn't due to copyright, it's due to the GPL being a Viral License. The concern <FUD> under the GPL. I'm not aware of this having been tested in court, but <FUD> there.

That tired old line was one of the many tools Microsoft attempted. Didnt work for them either. If you put gpled code into proprietary binaries without releasing source code what happens is a copyright infringement suit and damages if found to be infringing the copyright of the gpled code (if you don't respond to the formal warning and timelimits within beforehand) .

Microsoft's FUD wasn't that they claimed that the GPL does this, it was the extent to which they claimed that the GPL does this. Steve Ballmer claimed that if you use any open-source software under the GPL, all of your software has to be open-source. That's... just a straight-up lie, but it doesn't mean the GPL isn't viral or that it doesn't require the release of source code for projects that actually integrate GPL'd source.

If Oracle wins it's Java case in a final judgement against Google, Oracle will be motivated to find other suits. If ZFS Linux becomes widespread among consultants and users with deep pockets, then surely Oracle would sue for infraction.

Big companies are often involved in numerous legal disputes at any one time. I can't imagine Oracle would wait to see what happened in their suit against Google before going after people for using ZFS with Linux if they thought they had a good case and an opportunity to make money. The company employs 136,000 people and the way they behave sometimes you would think 135,000 of them must be lawyers!

The only time I could see them waiting would be if they needed the Google case to establish a particular legal precedent in advance of any action over ZFS.

If Oracle does win that is exactly what it would do. Any major commercial distros supporting ZFS officially are being very very stupid. If Oracle v Google sets a precident... Oracles only choice for the good of its shareholders would be to file.

I agree the current agreement should insulate actual users... but companies supporting it are asking for trouble. I also wonder what exposure cloud providers that support Linux installs with ZFS might be looking at.

I think ZFS is one of, scratch that it is probably the best file system going right now... but Oracle is simply not to be trusted. At anytime they could fix their licence... that they haven't tells me their army of lawyers is hedging their bets.

Jim, why is your bar business/enterprise use cases when your readership (and content) here is predominantly home use situations anyway? It is exceedingly rare that a home user would run a heavy VM or DB workload that would tip over btrfs. The average home user running a fileserver or home server should prioritize backups over raid anyway and benefits greatly from btrfs's flexibility. But if bitrot protection or snapshots are desired, it is hard to see where btrfs's raid implementation fails the home use case. The fact that btrfs has use cases that it isn't suitable for does not make it bad or less useful for the use cases that it is suitable for. I also think it is a little unfair to ridicule the btrfs-dev mailing list when we HAVE seen substantial fixes, including to parity raid, compression, and quotas.

I think you're seriously misguided here. for one, I'd wager you vastly underestimate the size of Ars's audience who work or are experienced in the professional/enterprise space.

Second, I highly doubt the "average home user" is running a file server. home users running a file server have to be a tiny, tiny sliver of the user base, and are likely to be pro/enterprise people using what they're familiar with in their work. FAT would likely suffice for the vast majority of home users if it wasn't for the addressing limitations.

First, read through Jim's articles (https://arstechnica.com/author/jimsalter/). Really seems targeted to techie/prosumer people. I'm not saying that's a bad thing and I'm not saying that sysadmin don't read this site, but this conversation section has rarely left me thinking I'm talking to adults or professionals. I read sysadmin forums and hang out in irc channels with sysadmin, and the topics/interests/content are very different.

Second, user base of what, OpenSUSE? Synology? LXD? Who do you think Synology's 2 drive or 4 drive form factors, sold with an easy UI and a high premium to build it yourself, are targeted to? btrfs does not need to appeal to a majority of users to valuable or useful. It can be a great option for narrow use cases and still be an excellent filesystem.

btrfs is getting dragged through the mud on this zfs conversation because it doesn't perfectly replace zfs in all possible scenarios, but my point is that is an unnecessarily high bar to hold it to. Why aren't we talking how great it is that Linux users have a featureful CoW filesystem with a friendly license that has stabilized dramatically to the point where it can be used reliably for many uses?