go go gadget nerdfight —

Linus Torvalds says “Don’t use ZFS”—but doesn’t seem to understand it

Enlarge/ Linus Torvalds is eminently qualified to discuss issues with license compatibility and kernel policy. However, this does not mean he's equally qualified to discuss individual projects in project-specific context.

Share this story

Last Monday in the "Moderated Discussions" forum at realworldtech.com, Linus Torvalds—founding developer and current supreme maintainer of the Linux kernel—answered a user's question about a year-old kernel maintenance controversy that heavily impacted the ZFS on Linux project. After answering the user's actual question, Torvalds went on to make inaccurate and damaging claims about the ZFS filesystem itself.

Given the massive weight automatically given Torvalds' words due to his status as founding developer and chief maintainer of the Linux kernel, we feel it's a good idea to explain both the controversial kernel change itself, and Torvalds' comments about both the change in question and the ZFS filesystem.

The original January 2019 controversy, explained

For those whose heads are spinning, kernel symbol exports expose internal information about the kernel state to loadable kernel modules. The particular symbol being discussed here, _kernel_fpu_, tracks the state of the processor's Floating Point Unit. Without access to that symbol, external kernel modules that access the FPU directly—as ZFS does—must implement state preservation code of their own. State preservation, whether in-kernel or native to kernel modules, makes sure that the original state of the FPU is restored before control is released to other kernel code that may be dependent on the values they last saw in the FPU's registers.

The technical impact of refusing to continue exporting the _kernel_fpu_ symbol is not to prevent modules from accessing the FPU directly—it only prevents them from using the kernel's own state-management facilities to preserve and restore state. Removing access to that symbol therefore requires module developers to reinvent their own state-preservation code individually. This increases the likelihood of catastrophic error within the kernel itself, since improperly restored state could cause a later kernel operation to crash.

Kroah-Hartman's defense of the decision to stop exporting the symbol to non-GPL kernel modules appeared to be driven largely by spite, as borne out by his own comment regarding the change: "my tolerance for ZFS is pretty non-existent." Normally, ZFS—on any platform, including the BSDs—uses SSE/AVX SIMD vector optimization to speed up certain operations. Without access to the _kernel_fpu_ symbol, ZFS developers were initially forced to disable the SIMD optimizations entirely, with fairly significant real-world performance degradation.

Although the change—and the way Kroah-Hartmann defended it—initially spawned a lot of drama and uncertainty, the long-term impact on the Linux ZFS community was fairly minimal. The breaking change only affected bleeding-edge kernels that few ZFS users were using in production, and in July 2019 new, in-module state management code was committed to the ZFS on Linux source tree.

“We don’t break users”

Torvalds' position in last Monday's forum post starts out reasonable and well-informed—after all, he's Linus Torvalds, discussing the Linux kernel. He notes that the famous kernel mantra "we don't break users" is "literally about user-space applications"—and so it does not apply to the decision to stop exporting kernel symbols to non-GPL kernel modules. By definition, if you're looking for a kernel symbol, you aren't a user-space application. The line being drawn here is a very bright and functional one: Torvalds is saying that if you want to run in kernel space, you need to keep up with kernel development.

From there, Torvalds branches out into license concerns, another topic on which he's accurate and reasonable. "Honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle," he writes. "Other people think it can be OK to merge ZFS code into the kernel and that the module interface makes it OK, and that's their decision. But considering Oracle's litigious nature, and the questions over licensing, there's no way I can feel safe in ever doing so."

He goes on to discuss the legally flimsy nature of the kernel module "shim" that the ZFS on Linux project (along with other non-GPL and non-weak-permissive projects, such as Nvidia's proprietary graphics drivers) use. There's some question as to whether they constitute a reasonable defense now—since nobody has challenged any project for using an LGPL shim for 20 years and running—but in purely logical terms, there isn't much question that the shims don't accomplish much. The real function of an LGPL kernel module shim isn't to sanction touching the kernel with non-GPL code, it's to protect the proprietary code on the far side of the shim from being forcibly published in the event of a GPL enforcement lawsuit victory.

So far, so good, but then Torvalds dips into his own impressions of ZFS itself, both as a project and a filesystem. This is where things go badly off the rails, as Torvalds states, "Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel... [the] benchmarks I've seen do not make ZFS look all that great. And as far as I can tell, it has no real maintenance behind it any more..."

“It was always more of a buzzword than anything else”

Further Reading

This jaw-dropping statement makes me wonder whether Torvalds has ever actually used or seriously investigated ZFS. Keep in mind, he's not merely making this statement about ZFS now, he's making it about ZFS for the last 15 years—and is relegating everything from atomic snapshots to rapid replication to on-disk compression to per-block checksumming to automatic data repair and more to the status of "just buzzwords."

There's only one other widely available filesystem that even takes a respectable stab at providing most of those features, and that's btrfs—which was not available for the first several years of ZFS' general availability. In fact, btrfs still isn't really stable enough for production use, unless you nerf all the features that make it interesting in the first place.

ZFS' per-block checksumming and automatic data repair has prevented data loss in my own real-world use many times, including this particularly egregious case of a SATA controller gone rabid. A standard RAID1 mirror would have cheerfully returned that 119GB of bad data with no warning whatsoever, but ZFS' live checksumming and error detection mitigated the whole thing to the point of never having to so much as touch a backup.

Further Reading

Meanwhile, atomic snapshots make it possible to keep a full block-for-block identical copy of storage at a point in time with negligible performance overhead and minimal storage overhead—and replication of those snapshots is typically hundreds or thousands of times faster (and more reliable) than non-filesystem-integrated solutions like rsync.

It's possible to not have a personal need for ZFS. But to write it off as "more of a buzzword than anything else" seems to expose massive ignorance on the subject.

Enlarge/ Yes, that's more than one MILLION blocks that returned bad data on one disk in the mirror—and another 18 on the other disk, just for good measure. "No known data errors."

505 Reader Comments

"Kroah-Hartman's decision to stop exporting the symbol to non-GPL kernel modules appeared to be driven largely by spite, as borne out by his own comment regarding the change: "my tolerance for ZFS is pretty non-existent."

But again, GKH's actual comment wasn't about "non-GPL kernel modules". This is the actual quote:

"My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly?"

I'm not going to pretend that they aren't being assholes here - Linus by criticizing tech he knows nothing about and avoiding any admission that he did so, GKH by essentially saying "fuck you, it's not ours so we're not touching it" (something he does a lot) - but that's not the same as saying "your software sucks because it's not GPL".

1999 - Dunning-Kruger Effect is a cognitive bias whereby people who are incompetent at something are unable to recognize their own incompetence.

IMO the substantive part of Linus’ statement was the licensing issue. This article spent 2/3 of its real estate talking about benchmarks. It’s important but to gain wide, legal use, who the f cares?

I guess you need catchy/emotionally charged titles to get people to click on your links. God I hate the internet.

Speak for yourself. Grow up and stop the Linus worship bullshit. The guy's opinions are not sacrosanct and this is far from the first time he's spoken completely out of his ass.

Where in this article is a legal analysis from a lawyer guaranteeing that if you incorporate ZFS code into the kernel, Oracle has zero chance of suing anyone? Please note that I'm not saying that Oracle won't win, but guaranteeing that they won't sue.

But Oracle would have no valid legal claim here. It would not be a very long or difficult lawsuit. And they might face sanctions for filing a claim where they clearly have no right to the property.

What's your legal reasoning to support this claim? How do you support your statement that Oracle would have no valid claim?

Edit: removed superfluous sentence.

Because the OpenZFS software is fully licensed.

xoa covered the patent angle in the post above in terms of impending expiry even assuming there were any related patents (are there?), but honestly I would actually argue that both copyright and patent would be covered by the license alone.

The fact that there's already an open source and highly protective license attached means Oracle really would have no valid angle and would likely get laughed out of court, short of someone being able to argue that there's some kind of truly formative issue in the license, and the problem then becomes that Oracle as the owner of the license would actually still have the brunt of any legal argument weighing against them in the case of anything being nebulous or poorly formed, rather than vice versa: you can't claim that you're simply invalidating a license you granted because you failed to construct it properly, the courts will always side on the part of the licensee in that case. The courts will look at the reasonably understood intent and expectations of a licensee, in terms of the reasonable person standard.

Honestly, I'm pretty sure that the varying objections and consternation in relation to Oracle having purchased Sun and therefor "touching" this, as it pertains to the OpenZFS derivative project, aren't reasonable, but it would require someone who's actually a contract law attorney to take a serious look at it.

At this point, I'd welcome someone to actually try presenting a cogent argument as to why there should be real concern over OpenZFS specifically in relation to Oracle that amounts to more than "because Oracle". I'm totally on the "because Oracle" side of things in general, but in this specific case I don't think there's an actual angle that wouldn't result in a summary dismissal if they tried taking it to court.

Who is "we" here? Is that referring to Ars? Or ZFS (given that the piece seems to be written from the perspective of a ZFS-adjacent dev unhappy that the project is being treated "unfairly")?

It's the editorial "we," referring to Ars. Get a job as a journalist, magically become plural!

Is that just the standard used when writing an editorial?

I don't like it. It makes it sound like the opinion comes from multiple people having sat down and formulated an opinion together. I don't think that was the case - these words are your own, are they not? They may have been tweaked by an editor, but the opinion is yours and yours alone, right?

We're getting into some inside baseball here, but while I am the actual author, this article made the rounds through the senior editorial staff over several days before publishing, with quite a few updates based on feedback. (Which isn't necessarily completely relevant to use of editorial "we," which is largely intended to distance the content of a news piece from the author.)

You might be happy to know that the editors don't even have a unanimous consensus on editorial "we" vs "I." Typically, the ones with journalism degrees prefer editoral "we" and the Johnny-come-latelies who are tacking the journalism part onto an existing tech career are less enthusiastic about it.

I'm one of those Johnny-come-latelies with no journalism degree myself, but I don't have super duper strong opinions about editoral "we" either way. My main gripe with it is it's more difficult/less natural to write, but where possible, I use it, on the grounds that it's consistent with Ars style guides.

IMO the substantive part of Linus’ statement was the licensing issue. This article spent 2/3 of its real estate talking about benchmarks. It’s important but to gain wide, legal use, who the f cares?

I guess you need catchy/emotionally charged titles to get people to click on your links. God I hate the internet.

Speak for yourself. Grow up and stop the Linus worship bullshit. The guy's opinions are not sacrosanct and this is far from the first time he's spoken completely out of his ass.

Where in this article is a legal analysis from a lawyer guaranteeing that if you incorporate ZFS code into the kernel, Oracle has zero chance of suing anyone? Please note that I'm not saying that Oracle won't win, but guaranteeing that they won't sue.

But Oracle would have no valid legal claim here. It would not be a very long or difficult lawsuit. And they might face sanctions for filing a claim where they clearly have no right to the property.

What's your legal reasoning to support this claim? How do you support your statement that Oracle would have no valid claim?

Edit: removed superfluous sentence.

Because the OpenZFS software is fully licensed.

xoa covered the patent angle in the post above in terms of impending expiry even assuming there were any related patents (are there?), but honestly I would actually argue that both copyright and patent would be covered by the license alone.

The fact that there's already an open source and highly protective license attached means Oracle really would have no valid angle and would likely get laughed out of court, short of someone being able to argue that there's some kind of truly formative issue in the license, and the problem then becomes that Oracle as the owner of the license would actually still have the brunt of any legal argument weighing against them in the case of anything being nebulous or poorly formed, rather than vice versa: you can't claim that you're simply invalidating a license you granted because you failed to construct it properly, the courts will always side on the part of the licensee in that case. The courts will look at the reasonably understood intent and expectations of a licensee, in terms of the reasonable person standard.

Honestly, I'm pretty sure that the varying objections and consternation in relation to Oracle having purchased Sun and therefor "touching" this, as it pertains to the OpenZFS derivative project, aren't reasonable, but it would require someone who's actually a contract law attorney to take a serious look at it.

At this point, I'd welcome someone to actually try presenting a cogent argument as to why there should be real concern over OpenZFS specifically in relation to Oracle that amounts to more than "because Oracle". I'm totally on the "because Oracle" side of things in general, but in this specific case I don't think there's an actual angle that wouldn't result in a summary dismissal if they tried taking it to court.

I will wager this is Canonical's position. It's telling that in 4 years, Oracle hasn't gone after them. They actually have money that can go towards Ellison's next yacht.

IMO the substantive part of Linus’ statement was the licensing issue. This article spent 2/3 of its real estate talking about benchmarks. It’s important but to gain wide, legal use, who the f cares?

I guess you need catchy/emotionally charged titles to get people to click on your links. God I hate the internet.

Speak for yourself. Grow up and stop the Linus worship bullshit. The guy's opinions are not sacrosanct and this is far from the first time he's spoken completely out of his ass.

Where in this article is a legal analysis from a lawyer guaranteeing that if you incorporate ZFS code into the kernel, Oracle has zero chance of suing anyone? Please note that I'm not saying that Oracle won't win, but guaranteeing that they won't sue.

But Oracle would have no valid legal claim here. It would not be a very long or difficult lawsuit. And they might face sanctions for filing a claim where they clearly have no right to the property.

What's your legal reasoning to support this claim? How do you support your statement that Oracle would have no valid claim?

Edit: removed superfluous sentence.

Because the OpenZFS software is fully licensed.

xoa covered the patent angle in the post above in terms of impending expiry even assuming there were any related patents (are there?), but honestly I would actually argue that both copyright and patent would be covered by the license alone.

The fact that there's already an open source and highly protective license attached means Oracle really would have no valid angle and would likely get laughed out of court, short of someone being able to argue that there's some kind of truly formative issue in the license, and the problem then becomes that Oracle as the owner of the license would actually still have the brunt of any legal argument weighing against them in the case of anything being nebulous or poorly formed, rather than vice versa: you can't claim that you're simply invalidating a license you granted because you failed to construct it properly, the courts will always side on the part of the licensee in that case. The courts will look at the reasonably understood intent and expectations of a licensee, in terms of the reasonable person standard.

Honestly, I'm pretty sure that the varying objections and consternation in relation to Oracle having purchased Sun and therefor "touching" this, as it pertains to the OpenZFS derivative project, aren't reasonable, but it would require someone who's actually a contract law attorney to take a serious look at it.

At this point, I'd welcome someone to actually try presenting a cogent argument as to why there should be real concern over OpenZFS specifically in relation to Oracle that amounts to more than "because Oracle". I'm totally on the "because Oracle" side of things in general, but in this specific case I don't think there's an actual angle that wouldn't result in a summary dismissal if they tried taking it to court.

Oracle has a few patents that mention ZFS, but I don't know if any of them touch on OpenZFS. They do own the trademark for ZFS though, and the grant terms in the CDDL specifically doesn't include any trademark rights. It also places some explicit limits on the patent rights granted under the license.

I still don't think that legal action from Oracle against Linux or other open source projects is likely here, but I do think there's a chance that they would try to extract settlement money from any majorly successful projects that relied on it. They probably wouldn't have a legal leg to stand on, but that hasn't stopped them before (and after the CAFC's last ruling in the Oracle v Google case, I'm not entirely confident that they need one).

xoa covered the patent angle in the post above in terms of impending expiry even assuming there were any related patents (are there?), but honestly I would actually argue that both copyright and patent would be covered by the license alone.

Yeah absolutely, at least when it comes to Oracle specifically as people have been raising concerns here. Has everyone commenting on the CDDL actually gone and read the thing? Like most open source licenses it's quite readable, short and to the point. If people are put off by thinking of EULAs don't be, unlike those which are trying to grab everything they can and dive deep into murky monetization justification and so forth, open source licenses benefit from much more minimal goals and straight forward foundations. And it's been gone over a fair amount since it came out too, a lot of questions in this thread would be answered by just reading the license.

So Oracle is definitely multiply covered here, by the license itself, by estoppel stemming from it and their later actions anyway, and finally from expiration entirely. Expiration will deal with non-Oracle entities too, which did come up for ZFS once in the form of that NetApp lawsuit (an incredible, incredible shame given that it was a major factor in halting Apple's march towards adopting it as their standard next filesystem). But the latter could apply to anything in Linux, FreeBSD or any other project already so it's not specific to OpenZFS.

Also, with the end of any patents in principle at least the OpenZFS community could decide to do a clean rewrite of all inherited code and do a forceful relicense that way. That may be too high a bar in practice, but it's an interesting possibility as technology marches forward.

Negative. 1G/1T is the recommendation WITHOUT dedup; the recommendation for dedup is an ADDITIONAL 5G/1T.

With that said, 1G/1T is a *guideline*, not a requirement, aimed at moderate to large fileservers servicing many concurrent, active users. It's entirely possible to run a 16T server with a single G of RAM allocated to ARC, your cache hit rates will just suck (as they would with any other file system), so you should expect the vast majority of reads to come off the metal.

You'll also need to rein in your enthusiasm for snapshots with an anemic ARC, as you also have less RAM available to cache METAdata, which can make performance get worse. (Ten snapshots, or even a hundred, are probably still fine. Get to 500, though, and you're probably kinda ducked if you do anything that actually REFERENCES those snapshots.)

In actual practice, I generally recommend using half the physical system RAM for ARC (which is the default on modern ZoL), and provisioning your system such that this adds up to at least 1G/1T if possible. Most of my VM hosts actually hit closer to 4-5G/1T. But 1. I can afford it, these are production systems with a lot of payroll accessing them in a business context, 2. It's not an absolute REQUIREMENT, and most crucially, 3. I'd be provisioning ext4 systems the same way, for the same reasons--but still not getting as high a cache hit rate as I do out of ZFS, let alone all the OTHER ZFS features I depend strongly on.

1TB of data with snapshots, average number of files, etc...uses around 100MB to 200MB of ARC metadata. The rest of your zfs allocated RAM will just be cache to speed up read hits. I've always heard 1GB of RAM for 1TB is for dedupe enabled as well and testing has more or less verified that for non-dedupe systems.

edit: I guess the difference between 200MB and 1GB isn't that much. I've actually never used dedupe or tested how much it adds to RAM as the discussions / training I had about it in the early 2010s with some ex-Sun guys was that a) only about 5% of use cases really benefit from dedupe and b) even in those cases compression is probably fine and it's not worth the memory usage unless you're REALLY gaining a lot of space over compression.

They do own the trademark for ZFS though, and the grant terms in the CDDL specifically doesn't include any trademark rights.

I'd think that would actually be by far the weakest argument though, because trademark remains very strictly use it or lose it. OpenZFS has been a thing for 7 years now. Would an attempt to go after it now even survive summary judgement? It definitely wouldn't survive much beyond that.

Quote:

It also places some explicit limits on the patent rights granted under the license.

Any possible window they have for that will slam shut in the next few years too though, however slim.

Quote:

I still don't think that legal action from Oracle against Linux or other open source projects is likely here, but I do think there's a chance that they would try to extract settlement money from any majorly successful projects that relied on it. They probably wouldn't have a legal leg to stand on, but that hasn't stopped them before (and after the CAFC's last ruling in the Oracle v Google case, I'm not entirely confident that they need one).

While legal caution around Oracle is certainly fair enough, I'd be equally worried about drawing too much from unrelated cases. The copyrightability of APIs was a legally novel argument, however evil and bad a one. Licensing and estoppel aren't. Any target making enough money for Oracle to care about would also be making enough to take on such an open-shut case. Letting the mere threat of a baseless suit carry too much weight is itself a decision that causes harm too.

I mean, imagine someone would write entire articles and have HN discussions and whatnot just because you said a slightly silly thing at the end of an on-topic comment here on Ars. Would probably not be a great experience.

I don't have to imagine it; I occasionally live it. (At least the HN part.)

edit: probably also worth mentioning, I'm a lot more careful about what I say, particularly when it comes to negging on someone's project, writing as an Ars Technica author than I used to be as "some random person on the internet." There's a bit of a Spider-Man/Uncle Ben thing ("with great power...") going on when you speak from a tall pulpit, and your words can have a much broader/deeper impact due to it.

They do own the trademark for ZFS though, and the grant terms in the CDDL specifically doesn't include any trademark rights.

I'd think that would actually be by far the weakest argument though, because trademark remains very strictly use it or lose it. OpenZFS has been a thing for 7 years now. Would an attempt to go after it now even survive summary judgement? It definitely wouldn't survive much beyond that.

Quote:

It also places some explicit limits on the patent rights granted under the license.

Any possible window they have for that will slam shut in the next few years too though, however slim.

Quote:

I still don't think that legal action from Oracle against Linux or other open source projects is likely here, but I do think there's a chance that they would try to extract settlement money from any majorly successful projects that relied on it. They probably wouldn't have a legal leg to stand on, but that hasn't stopped them before (and after the CAFC's last ruling in the Oracle v Google case, I'm not entirely confident that they need one).

While legal caution around Oracle is certainly fair enough, I'd be equally worried about drawing too much from unrelated cases. The copyrightability of APIs was a legally novel argument, however evil and bad a one. Licensing and estoppel aren't. Any target making enough money for Oracle to care about would also be making enough to take on such an open-shut case. Letting the mere threat of a baseless suit carry too much weight is itself a decision that causes harm too.

Granted that this could just be an over-eager legal firm shooting before looking, but this sort of nonsense is pretty commonplace coming from Oracle and it can be a burden, even if it never makes it to a proper trial. I know that any organization with enough money for them to properly chase would probably have enough money to end the case quickly, but I'm also not willing to put it past Oracle's legal team to demand a nuisance settlement.

EDIT: Also, just to be clear: this isn't really the major obstacle here. I think it's a concern, but it's a concern with a lot of the stuff that Sun's touched (and with anything Oracle could claim patent rights over, which could be pretty well anything) so it's probably not worth rejecting a project unless that project is really niche. The real issue's just the incompatibility of the CDDL and GPL licenses and the fact that Oracle would have to sign off on any relicensing efforts.

Negative. 1G/1T is the recommendation WITHOUT dedup; the recommendation for dedup is an ADDITIONAL 5G/1T.

With that said, 1G/1T is a *guideline*, not a requirement, aimed at moderate to large fileservers servicing many concurrent, active users. It's entirely possible to run a 16T server with a single G of RAM allocated to ARC, your cache hit rates will just suck (as they would with any other file system), so you should expect the vast majority of reads to come off the metal.

You'll also need to rein in your enthusiasm for snapshots with an anemic ARC, as you also have less RAM available to cache METAdata, which can make performance get worse. (Ten snapshots, or even a hundred, are probably still fine. Get to 500, though, and you're probably kinda ducked if you do anything that actually REFERENCES those snapshots.)

In actual practice, I generally recommend using half the physical system RAM for ARC (which is the default on modern ZoL), and provisioning your system such that this adds up to at least 1G/1T if possible. Most of my VM hosts actually hit closer to 4-5G/1T. But 1. I can afford it, these are production systems with a lot of payroll accessing them in a business context, 2. It's not an absolute REQUIREMENT, and most crucially, 3. I'd be provisioning ext4 systems the same way, for the same reasons--but still not getting as high a cache hit rate as I do out of ZFS, let alone all the OTHER ZFS features I depend strongly on.

1TB of data with snapshots, average number of files, etc...uses around 100MB to 200MB of ARC metadata. The rest of your zfs allocated RAM will just be cache to speed up read hits. I've always heard 1GB of RAM for 1TB is for dedupe enabled as well and testing has more or less verified that for non-dedupe systems.

edit: I guess the difference between 200MB and 1GB isn't that much. I've actually never used dedupe or tested how much it adds to RAM as the discussions / training I had about it in the early 2010s with some ex-Sun guys was that a) only about 5% of use cases really benefit from dedupe and b) even in those cases compression is probably fine and it's not worth the memory usage unless you're REALLY gaining a lot of space over compression.

I don't have time to retype everything on the subject of ZFS dedup, but the concise version is "it sucks for almost everyone, and you almost certainly shouldn't use it." If you have a dedup ratio of 50:1 or better, it might be worth your while... but, spoiler, you almost certainly don't or won't unless you've got a very unusual use case.

The author writes: Kroah-Hartman's decision to stop exporting the symbol to non-GPL kernel modules appeared to be driven largely by spite, as borne out by his own comment regarding the change: "my tolerance for ZFS is pretty non-existent."

But following the link, what he actually said was: "Yes, the 'GPL condom' attempt doesn't work at all. It's been shot down a long time ago in the courts. My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly?"

So is that "spite" or just "frustration." I'm not sure but I can guess what a GPL condom is. I can't quite parse what the problem is that their facing but I think the author is oversimplifying that person's stance. Maybe out of spite?

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."

It's tainted by Oracle code, it can never be trusted

I could be wrong, but I seem to remember that the mainline development of XFS support in the Linux kernel is maintained by an Oracle employee.

I remember briefly trying the "new" FreeNAS...and performance on the same box was shit. Everyone told me I needed like 10x more RAM than my system supported even though I didn't turn on anything extra.

I wiped installed CentOS with EXT4 and the appropriate services, I was zipping along saturating a gigabit LAN with minimal resource consumption.

Replacing FreeNAS/ZFS with CentOS/EXT4 is like replacing an 18 wheeler with a Civic. Yes, they will both get you places, but their capabilities and intended use cases aren't comparable.

The original FreeNAS before they redid and added in ZFS ran on the same hardware just fine...back then it was UFS filesystem

I remember briefly trying the "new" FreeNAS...and performance on the same box was shit. Everyone told me I needed like 10x more RAM than my system supported even though I didn't turn on anything extra.

I wiped installed CentOS with EXT4 and the appropriate services, I was zipping along saturating a gigabit LAN with minimal resource consumption.

Replacing FreeNAS/ZFS with CentOS/EXT4 is like replacing an 18 wheeler with a Civic. Yes, they will both get you places, but their capabilities and intended use cases aren't comparable.

The original FreeNAS before they redid and added in ZFS ran on the same hardware just fine...back then it was UFS filesystem

It's anecdotal, but I have FreeNAS running at home on an old Celeron 2807 system with 4GB of RAM. I usually saturate the network before I hit any performance bottlenecks from the hardware + ZFS.

The author writes: Kroah-Hartman's decision to stop exporting the symbol to non-GPL kernel modules appeared to be driven largely by spite, as borne out by his own comment regarding the change: "my tolerance for ZFS is pretty non-existent."

But following the link, what he actually said was: "Yes, the 'GPL condom' attempt doesn't work at all. It's been shot down a long time ago in the courts. My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly?"

So is that "spite" or just "frustration." I'm not sure but I can guess what a GPL condom is. I can't quite parse what the problem is that their facing but I think the author is oversimplifying that person's stance. Maybe out of spite?

A "GPL condom" is a bit of GPL-compatible code that you place between the kernel and some non-GPL-compatible code so that the non-GPL code doesn't have to be GPL-licensed.

Also, there's definitely some spite there. I can see at least two layers:

- GKH is generally spiteful of people who expect the kernel team to support their kernel-level code but aren't willing to provide that code with the kernel, regardless of the reasons why.

- GKH is specifically spiteful of the people who created this license, because they created the license knowing that it would be incompatible with the GPL (which also makes it incompatible with the Linux code base).

GKH is usually a really pleasant guy from what I've seen, but on this specific stuff his shoulder definitely shows a chip.

Keeping in mind Linus himself has admitted in the past to being an uninformed jackass and doesn't really care about what other people think, this stance shouldn't shock anyone. It would be more newsworthy if he came out and said they were wrong for making the change.

Having seen and engaged in "conversations" with him on RealWorldTech in the past, I agree. He's a major asshole, doesn't apparently ready what people write in favor of inventing something offensive so that he has an excuse to be insulting, and falsely thinks he knows everything about everything -- even to the point of claiming that climate change isn't happening.

In other words while he's knowledgeable about some things, he's also a classic example of the Dunning-Kruger syndrome in action.

In fact, btrfs still isn't really stable enough for production use, unless you nerf all the features that make it interesting in the first place.

Bullshit

Nope, quite true. SUSE uses only a very limited subset of it. Synology is the same, they for example use Linux md raid underneath a limit slice of it (and I think punch through the information from that with custom patches?). Red Hat outright deprecated it a few years back, considering it not production ready. BTRFS RAID5/6 still has the write hole, and is still firmly in "do not use if you care about your data" territory with critical data loss bugs. I've seen multiple unrecoverable data losses on btrfs, and people report unrecoverable bugs and get no interest from development beyond "wipe and try again". Snapshots aren't even done yet. Some of this is beta-ness, but some looks like results from choices made in the on-disk structures and other feature efforts. Like, one of the things that always gets brought up about ZFS are limitations around removing devices/resizing pools, whereas btrfs has a form of restriping. But restriping seems like a real failure source too, ZFS never overwriting anything is a fundamental limitation on the potential for normal operations to introduce unrecoverable data errors.

Dunno, you can roll the dice if you want, and big organizations might have the internal development firepower to get whatever useful they can out of it and deal with the many, many warts. But there really are strong reasons why so many do not consider it generally production stable.

Keeping in mind Linus himself has admitted in the past to being an uninformed jackass and doesn't really care about what other people think, this stance shouldn't shock anyone. It would be more newsworthy if he came out and said they were wrong for making the change.

Having seen and engaged in "conversations" with him on RealWorldTech in the past, I agree. He's a major asshole, doesn't apparently ready what people write in favor of inventing something offensive so that he has an excuse to be insulting, and falsely thinks he knows everything about everything -- even to the point of claiming that climate change isn't happening.

In other words while he's knowledgeable about some things, he's also a classic example of the Dunning-Kruger syndrome in action.

To be fair, Linus has made a concerted effort to stop being an offensive dickbag and there's been a staggering improvement in his behavior. Case in point: he didn't insult or demean the person he was responding to here. He did make some unjustified comments about ZFS, but they weren't insulting so much as just... well, wrong.

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.

100X this! The FreeNAS "requirements" are to keep completely tech-oblivious people out of trouble.

If have more than 4 GB of free memory after your OS/apps are loaded, you can run ZFS without issue. No, your ARC won't be huge. No, you can't buffer monster writes. But it won't go up in flames and destroy your data, it won't be unusably slow for a NAS, etc.

FreeNAS junkies and the forum admins/zealots (a few of which have been removed, thankfully) have done more damage to the ZFS name than anyone else in recent years. I say that as someone who runs FreeNAS, but only listen to them for FreeNAS-specific things. All of the ZFS particulars from them are ignored.

EDIT: I am a little biased - I run hundreds of PiB of ZFS storage as part of my day job.

Negative. 1G/1T is the recommendation WITHOUT dedup; the recommendation for dedup is an ADDITIONAL 5G/1T.

With that said, 1G/1T is a *guideline*, not a requirement, aimed at moderate to large fileservers servicing many concurrent, active users. It's entirely possible to run a 16T server with a single G of RAM allocated to ARC, your cache hit rates will just suck (as they would with any other file system), so you should expect the vast majority of reads to come off the metal.

You'll also need to rein in your enthusiasm for snapshots with an anemic ARC, as you also have less RAM available to cache METAdata, which can make performance get worse. (Ten snapshots, or even a hundred, are probably still fine. Get to 500, though, and you're probably kinda ducked if you do anything that actually REFERENCES those snapshots.)

In actual practice, I generally recommend using half the physical system RAM for ARC (which is the default on modern ZoL), and provisioning your system such that this adds up to at least 1G/1T if possible. Most of my VM hosts actually hit closer to 4-5G/1T. But 1. I can afford it, these are production systems with a lot of payroll accessing them in a business context, 2. It's not an absolute REQUIREMENT, and most crucially, 3. I'd be provisioning ext4 systems the same way, for the same reasons--but still not getting as high a cache hit rate as I do out of ZFS, let alone all the OTHER ZFS features I depend strongly on.

1TB of data with snapshots, average number of files, etc...uses around 100MB to 200MB of ARC metadata. The rest of your zfs allocated RAM will just be cache to speed up read hits. I've always heard 1GB of RAM for 1TB is for dedupe enabled as well and testing has more or less verified that for non-dedupe systems.

edit: I guess the difference between 200MB and 1GB isn't that much. I've actually never used dedupe or tested how much it adds to RAM as the discussions / training I had about it in the early 2010s with some ex-Sun guys was that a) only about 5% of use cases really benefit from dedupe and b) even in those cases compression is probably fine and it's not worth the memory usage unless you're REALLY gaining a lot of space over compression.

I don't have time to retype everything on the subject of ZFS dedup, but the concise version is "it sucks for almost everyone, and you almost certainly shouldn't use it." If you have a dedup ratio of 50:1 or better, it might be worth your while... but, spoiler, you almost certainly don't or won't unless you've got a very unusual use case.

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?

Ninja'ed by Morhyn and rabish12

ZFSv28 was released as part of OpenSolaris prior to the purchase of SUN by Oracle. Shortly thereafter, Oracle closed down the OpenSolaris project and made everything proprietary. ZFSv29 was released awhile later as part of Oracle Solaris.

Shortly thereafter, Illumos was released as a continuation of the OpenSolaris project, and the included reference version of ZFS was updated to ZFSv5000 using feature flags instead of specific version numbers. This became OpenZFS.

You can specify the pool version and feature flags to enable/disable when you create the pool. If you specify ZFSv28 at pool creation time, then you can import that pool using Oracle ZFS, OpenZFS, Sun ZFS, etc. That is the only bit of compatibility between OpenZFS and Oracle ZFS. If you specify any version greater than 28 then it will only work with Oracle ZFS; if you enable any feature flags, then it will only work with OpenZFS.

All of the code in OpenZFS was released under the CDDL prior to the SUN aquisition by Oracle. There's virtually no possible way for Oracle to retroactively go back and revoke that license. And the CDDL includes all the patent protections (it's why SUN chose the CDDL instead of the GPL/BSDL/other licenses). So there's virtually no possible way Oracle could sue anyone using OpenZFS. (If there was, don't you think they'd have jumped on that already, instead of waiting 10 years?)

ZFS has a lot going for it but it also has a lot of problems both administratively and technically. Things that LVM has been able to do for years (evacuate a drive from the array) can't be done in ZFS.

Inaccurate. You've been able to remove top-level vdevs for awhile now. You can't do it in root pools, but non-root/storage pools you can. Have a multi-raidz vdev pool and you accidentally add a drive (creating a non-redundant single-disk vdev) instead of replace it? No problem, you can remove it and try again.

The only major downside remaining is that you can't change the layout of raidz vdevs (meaning, you can't expand a 4-disk raidz1 to a 5-disk raidz1; or remove drives from a raidz vdev; or convert from a raidz1 to a raidz2; things like that). So you have to plan your pool layout up front, before you actually create it; with an eye to how you will expand the pool (add vdevs) in the future.

To be fair, Linus has made a concerted effort to stop being an offensive dickbag and there's been a staggering improvement in his behavior. Case in point: he didn't insult or demean the person he was responding to here. He did make some unjustified comments about ZFS, but they weren't insulting so much as just... well, wrong.

True, but it's going to take a lot more than that to raise my opinion of him from "Dunning-Kruger asshat" to "human" -- but at least he's ahead of one particular public figure who's renowned for his sharpie retcon... at least Linus HAS knowledge in some areas.