Live data from Hacker News

Linus: Don't Use ZFS

realworldtech.com

211–220 of 571 posts

Re: Linus: Don't Use ZFS

#211
post #170

Earlier quoted context omitted.

If I remember correctly, the reasoning for the GPL module stuff was/is, that if kernel modules integrate deeply with the kernel, they fall under gpl. So the GPL flag is basically a guideline of what kernel developers believe is safe to use from non gpl-compatible modules

This is the commonly recited argument but I don't believe it was ever proven to be legally necessary. Furthermore, even if it was, it's not clear what level of integration is "too deep". So in practice, it's just a way for kernel developers to add political restrictions as they see fit.

"Proven" is a maybe impossible standard: Kernel devs hint at the GPLonly exports having been useful in certain cases they prefer not to discuss on a ML. https://lore.kernel.org/lkml/20190110131132.GC20217@kroah.co...

One can interpret this as something legally significant, or an embarrassing private anecdote, or nothing substantial at all, maybe even just talk. However, I'd give them the benefit of the doubt. Not the least since they could be the ones against Oracle's legal dept...

Re: Linus: Don't Use ZFS

#212
post #166

Earlier quoted context omitted.

I'm baffled by such arguments. > It doesn't seem to be well-maintained. The last commit is from 3 hours ago: https://github.com/zfsonlinux/zfs/commits/master . They have dozens of commits per month. The last minor release, 0.8, brought significant improvements (my favorite: FS-level encryption). Or maybe this is referred to the 5.0 kernel (initial) incompatibility? That wasn't the ZFS dev team's fault. > Performance…

bcachefs should be heavily supported, it doesn't get nearly enough for what it supposes to do: https://www.patreon.com/bcachefs

I've been looking forward to using bcachefs as I had a few bad experiences with btrfs.

Is bcachefs more-or-less ready for some use cases now? Does it still support caching layers like bcache did?

Re: Linus: Don't Use ZFS

#213

Earlier quoted context omitted.

> And I'm not at all interested in some "ZFS shim layer" thing either If there is no "approved" method for creating Linux drivers under licenses other than the GPL, that seems like a major problem that Linux should be working to address. Expecting all Linux drivers to be GPL-licensed is unrealistic and just leads to crappy user experiences. nVidia is never going to release full-featured GPL'd drivers, and even corpor…

There is an "approved" method - write an publish your own kernel module. However if your module is not GPL licensed it cannot be published in the linux kernel itself, and you must keep up with the maintenance of the code. This is a relatively fair requirement imo.

...which is what the ZFS on Linux team are doing?

The issue here is which parts of the kernel API are allowed for non-GPL modules has been decided to be a moving target from version to version, which might as well be interpreted as "just don't bother anymore".

Re: Linus: Don't Use ZFS

#214
post #138

He's not wrong. ext4 is actually maintained. This matters. ZFS hasn't kept up with SSDs. ZFS partitions are also almost impossible to resize, which is a huge deal in today's world of virtualized hardware. Honestly Linus's attitude is refreshing. It's a sign that Linux hasn't yet become some stiff design-by-committee thing. One guy ranting still calls the shots. I love it. Protect this man at all costs.

zfsonlinux added support for TRIM last year. Are you referring to something else?

Re: Linus: Don't Use ZFS

#215

Earlier quoted context omitted.

They harass universities about it too. Which is ludicrous, because universities often have residence halls, and people who live there often download VirtualBox extensions.

Their PUEL license even has a grant specifically for educational use.

It does, but it's not 100% clear if administrative employees of universities count as educational. Sure, if you are teaching a class with it, go for it; but running a VM in it for the university accounting office is not as clear.

Re: Linus: Don't Use ZFS

#216
post #46

Earlier quoted context omitted.

Pretty much my view as well. If Linux becomes incompatible with ZFS in any way, I'll switch to FreeBSD. That said, after the Oracle Java debacle, I can see why Linus would not be receptive towards merging ZFS into the kernel. I just wish he argued the point on legal issues alone instead of making up stories about non-existent technical flaws in ZFS. The whole thing is basically a work of art. Oracle should consider G…

I have been using FreeBSD for its better ZFS support for years, and it's great. Highly recommended.

Same here. I immediately ditched Solaris (hated it) for Linux when KQ Infotech ported ZFS over about a decade ago, but after a few years switched all my file servers to FreeBSD. ZFS > Linux. Did I mention I love Linux?

Re: Linus: Don't Use ZFS

#217
post #42

Earlier quoted context omitted.

> The benchmarks I've seen do not make ZFS look all that great. The thing about ZFS that actually appeals to me is how much error-checking it does. Checksums/hashes are kept of both data and metadata, and those checksums are regularly checked to detect and fix corruption. As far as I know it (and filesystems with similar architectures) are the only ones that can actually protect against bit rot. https://github.com/zf…

> those checksums are regularly checked to detect and fix corruption. I don't believe that's true. They are checked on access, but if left alone, nothing will verify them. From what I've read, you need to setup a cron job that runs scrubbing on some regular schedule.

Yes. Those cron jobs are installed by default by all major vendors that supply/support ZFS.

Re: Linus: Don't Use ZFS

#218
post #157

Earlier quoted context omitted.

>This is done strictly for political reasons and has no known legal basis as far as I'm aware. let me stop you right there. This being "Oracle," and its litigious nature, how can you truly be aware or sure? Linus is literally saying there is a legal basis.

> This being "Oracle," and its litigious nature, how can you truly be aware or sure? The functionality I'm describing has absolutely nothing to do with ZFS or Oracle in any way. If you really think the reach of Oracle is so great, then why not block all Oracle code from ever running on the OS? That seems to me to be just as justified as this change.

> why not block all Oracle code from ever running on the OS?

...to be fair, I would probably run that module.

Re: Linus: Don't Use ZFS

#219
post #45
post #13

Earlier quoted context omitted.

Relevant bits: "Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me. 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 either any more, so from a long-term stability standpoint, why would you ever want to use it in the first place?"

Linus is just wrong as far as maintenance, as a look at the linux-zfs lists would show. From my perspective, it has no real competitor under linux, which is why I use it. I don't consider brtfs mature enough for critical data. (Others can reasonably disagree, I have intentionally high standards for data durability.) Aside from legal issues, he's talking out of his ass.

I don't care about my data, so I use ext4, and like most non-ZFS peasants I lose files every other day.

Re: Linus: Don't Use ZFS

#220
post #41
post #7

Earlier quoted context omitted.

That's his reasoning for not merging ZFS code, not for generally avoiding ZFS.

The problem with ZFS is that it isn't part of Linux kernel. Linux project maintains compatibility with userspace software but it does not maintain compatibility with 3rd party modules and for a good reason. Since modules have access to any internal kernel API it is not possible to change anything within kernel without considering 3rd party code, if you want to keep that code working. For this reason the decision was…

It isn't just ZFS. All sorts of drivers get broken because Linux refuses to offer a stable API, saying your code should be in the kernel, but also often refuses to accept drivers into the kernel, even open-source code with no particular quality issues (e.g. quickcam, reiserfsv4).

Use FreeBSD where there's a stable ABI and you don't have these problems.

Post reply on HN