Linus Torvalds Doesn't Recommend Using ZFS On Linux

Status
Not open for further replies.
Linux kernel creator Linus Torvalds doesn't recommend using ZFS On Linux at least until Oracle were to re-license the code to make it friendly for mainline inclusion. But even then he doesn't seem turned on by the ZFS features or general performance.

Derailed from the recent mailing list discussion over Torvalds' thoughts on the Linux kernel scheduler, he responded to a post of a user complaining about the Linux kernel recently breaking the out-of-tree ZFS module.

Of course, Linus Torvalds has little control over the behavior of out-of-tree modules and it's always been his position to not maintain a stable driver API/ABI and they won't bend over backwards for closed-source/out-of-tree code. Out-of-tree modules are basically treated like they don't exist.

Linus wrote of ZFS on Linux:
Note that "we don't break users" is literally about user-space applications, and about the kernel I maintain.

If somebody adds a kernel module like ZFS, they are on their own. I can't maintain it, and I can not be bound by other peoples kernel changes.

And honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd.

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.

And I'm not at all interested in some "ZFS shim layer" thing either that some people seem to think would isolate the two projects. That adds no value to our side, and given Oracle's interface copyright suits (see Java), I don't think it's any real licensing win either.

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?
 
ZFS with GPL problems are not our problems.

Also, ZFS isn't as focused so much on performance as much as not losing your data, so in that regard, I'm not sure his opinion matters.

As for maintenance, there seems to be no shortage of people wanting to twiddle with it, just maybe too many forks.
 
Linus is a kernel developer, he's not a zfs developer; therefore he talks through his posterior and his opinion doesn't matter.
Regardless, my reading of it is he hates the licensing so he hates the software, which is hypocritical given the binary blobs scattered in his kernel. He's a supporter of GPL so he's the problem not zfs.
GPL is evil.
 
As for user end applications GPL is great. For dependencies, and libraries meant for multiple apllications to use, it's terrible. I'm not sure if the license is the cause for bloat, but the tw go together, and maybe encourage it. Certainly, it is misused. When they change their license to incorporate a freer license, it's a terrible showing of that culture, so that reason behind a GPL is really bad.

As far as I see, a story about Linus and Bill Gates makes me think he's short sighted. Bill gates attempted to rip him off once, and Linus didn't go for it. So, Gates immediately tried again, and how did he not figure out, if he tried to rip him off once, the next attempt would be to rip him of and not be gratuitous. First, Gates offered him maybe 10%, which would have been a ripoff. Then Gates offered him 90%. Linus would get a percentage of zero. Even if one couldn't see what the scam would be, how could you not know if he tried once, he'll try again.

So for his critiques on anything, you would have to consider he can't think ahead.
 
I believe the ZFS codebase is pretty massive. Potentially one day if people get bored of it, it will be quite a large maintenance task.

Also, if Linux really is striving for GPL; having a perfectly good ZFS in the tree will potentially discourage developers to start a new GPL based one from scratch.
 
This is Linux, there is a new one started from scratch every week and then abandoned before they finish it --- like BTRFS.
Exactly. And while BTRFS (I mean the one that eventually became the default on SUSE) was striving to copy ZFS's features, it never got most of them to work. And then it turned into a machine for creating data loss.

Oh, and you forgot to mention BTRFS (there are two with that name!) and BETRFS. Everyone who thinks they can implement a file systems starts doing so. And they all use Linux as the development platform. Now, it would be unfair to claim that this is the "fault of Linux", or that there is an evil Linux cabal trying to destroy the universe by creating bad file systems. Don't ascribe to malice what can be explained by incompetence! It's just random people who want to play with file systems, they happen to use Linux, they ship it as freely available software, and suddenly Linux has a lot more file systems.

In the meantime, we have the very good ext<n> series of file systems (not feature reach, no built-in data protection, but very well engineered, and reliable), and we have good of XFS (written by professional engineers at SGI, instead of drunk college kids), and we have ZFS. All very good file systems, although ZFS does stand out in data protection.

And since Linus has never been a working software engineer, and even less the leader of a software engineering organization, nor an expert in storage and file systems, his judgement calls on these topics are simply meaningless. And the people in the Linux ecosystem who make deployment decisions know that, and will ignore his rant. While in the meantime every paranoid and sensationalist drunk kid in the blogosphere will be claiming that the sky is falling, as is happening here on this forum right now.
 
This is Linux, there is a new one started from scratch every week and then abandoned before they finish it --- like BTRFS.
I think this is so true.
Over the years of observing (and sometime using) Linux, I have come to these conclusions about the Linux ecosystem:
1) A stable software subsystem (for example, init) is seen as dangerously unmaintained because no bugs have been submitted for it in over a year and is therefore in need of immediate replacement.
2) "Not Invented Here" syndrome.
3) If it isn't GPLvN, then they need to make it GPLvN or otherwise they will denigrate it as useless and not Linux compatible.
4) Linux is an incoherent mess with far too many developers wanting to add their own to it. It's bloated and slow (and even Torvalds thinks this!)

Don't get me wrong, I think it has it use cases, but overall I would recommend Windows over Linux.
 
I believe the ZFS codebase is pretty massive. Potentially one day if people get bored of it, it will be quite a large maintenance task.

Also, if Linux really is striving for GPL; having a perfectly good ZFS in the tree will potentially discourage developers to start a new GPL based one from scratch.


And it will only get more massive because Linux developers now have control of it. Feature creep and useless additions will become the norm; it's the Linux way. They hate stability. You watch.

The nail in the coffin will be when they integrate systemd into it... LOL
 
Init has limitations, so people want to solve them. I wouldn't blame them for wanting something better... unfortunately "better" seems to be in the eyes of whatever RedHat decides, because he who writes the code, writes the rules.
 
The GPL3 seems parasitic as how it seemed to be based to take advantage of a newer BSD license. But the BSD license allows it, and there's no clear way to keep it for some free purposes and not for others. As long as it promotes good code, and isn't blocked by copyright trolls or an organization that tries to retroactively claim that code.

As for the entire movement, I can't say they're bad, because applications like Audacity, Ardour and Libreoffice which are for unselfish purposes have a GPL license. I've used those programs for what they're meant for.

I wonder if much of the bloat in GPL has to do with the license saying you must give back code, then everyone gives up code, which is a pile on because they feel compelled to do it. But I would say, it's from multiple organizations who want to combo license software to GPL, then they don't bother fixing major problems, because they don't want to give up improvements to a competitor who uses that same licensed program. I also suspect that RedHat and Gnome want things to be complicated on purpose.

There are cases where for-profit organizations using GPL works well and is unselfish, like Asterisk for instance. In cases where an application has too many uses, then GPL doesn't work well from for profits. GPL and similar licensing also works well for hobbyist applications or for those using applications largely created by an organization that wasn't code just skimmed off of another application with a less restrictive license.

GPL licensed code for widely available hardware not created by that organization? Now that's bad.
 
Seems that many BSD users are against ZoL being included into future FreeBSD. I also agree that FreeBSD shouldn't include ZoL for the main reason.. Linux communities have proven to be unreliable especially with their own history with BTRFS. They'll will make ZoL much worse and unreliable. FreeBSD ZFS has proven to be very solid and I've been running several servers with ZFS for over 5 years with no data loss. BTRFS can't even do it. I think FreeBSD should maintain their own ZFS apart from ZoL because one day ZoL will be a catastrophic failure waiting to happen.
 
Exactly. And while BTRFS (I mean the one that eventually became the default on SUSE) was striving to copy ZFS's features, it never got most of them to work. And then it turned into a machine for creating data loss.

Oh, and you forgot to mention BTRFS (there are two with that name!) and BETRFS. Everyone who thinks they can implement a file systems starts doing so. And they all use Linux as the development platform. Now, it would be unfair to claim that this is the "fault of Linux", or that there is an evil Linux cabal trying to destroy the universe by creating bad file systems. Don't ascribe to malice what can be explained by incompetence! It's just random people who want to play with file systems, they happen to use Linux, they ship it as freely available software, and suddenly Linux has a lot more file systems.

In the meantime, we have the very good ext<n> series of file systems (not feature reach, no built-in data protection, but very well engineered, and reliable), and we have good of XFS (written by professional engineers at SGI, instead of drunk college kids), and we have ZFS. All very good file systems, although ZFS does stand out in data protection.

And since Linus has never been a working software engineer, and even less the leader of a software engineering organization, nor an expert in storage and file systems, his judgement calls on these topics are simply meaningless. And the people in the Linux ecosystem who make deployment decisions know that, and will ignore his rant. While in the meantime every paranoid and sensationalist drunk kid in the blogosphere will be claiming that the sky is falling, as is happening here on this forum right now.

EXT3 was very limited (even in its times) with 2TB file limit.

EXT4 almost killed KDE project because they (KDE) lost almost all of their repositories because of bugs in EXT4 filesystem:

XFS with metadata checksums is least shit in Linux native filesystems world, but XFS still does not provide data consistency like ZFS does.

BTRFS is currently ok in RAID0/RAID1 mode.

There is also project STRATIS in Red Hat which takes XFS over LVM to 'imitate' ZFS (so pathetic :ASD) and they plan to achieve checksums for data somewhere in the future - like in next 3-5 years of STRATIS development.
 
Init has limitations, so people want to solve them. I wouldn't blame them for wanting something better... unfortunately "better" seems to be in the eyes of whatever RedHat decides, because he who writes the code, writes the rules.
Actually, init does not have limitations. That's scope creep. Init starts the processes and then reaps the dead processes. Period.
 
The GPL3 seems parasitic as how it seemed to be based to take advantage of a newer BSD license. But the BSD license allows it, and there's no clear way to keep it for some free purposes and not for others. As long as it promotes good code, and isn't blocked by copyright trolls or an organization that tries to retroactively claim that code.

You could go back to the original BSD with the 'advertising' clause. We know that's not GPL compatible. ;)
 
Seems that many BSD users are against ZoL being included into future FreeBSD. I also agree that FreeBSD shouldn't include ZoL for the main reason.. Linux communities have proven to be unreliable especially with their own history with BTRFS. They'll will make ZoL much worse and unreliable. FreeBSD ZFS has proven to be very solid and I've been running several servers with ZFS for over 5 years with no data loss. BTRFS can't even do it. I think FreeBSD should maintain their own ZFS apart from ZoL because one day ZoL will be a catastrophic failure waiting to happen.
I totally agree.
Scope creep is part of the Linux ethos, it seems. It will soon become so bloated and so cumbersome that it will be down to a niche few developers looking after it. So if Lawrence Livermore National Laboratory suddenly loses interest after years of bloat creation, you're screwed.

I don't know the specifics, but I hope the development of ZFS is done so that FreeBSD (or NetBSD for that matter) can pull in what they want and still have a functioning ZFS.
 
overall I would recommend Windows over Linux.

I'm afraid I feel the same way. Some years ago I liked Linux hugely better, but it's lost all that ground. Of course FreeBSD leaves both of them in the dust.
Actually, init does not have limitations

From my limited understanding the big complaint with init is that it can't load processes in parallel. Seems to me like a small justification for replacing it with something largely more complicated, more monolithic, and more prone to issues (aside from its poorly written code). So what's the big advantage, some milliseconds saved at boot?
 
I think FreeBSD should maintain their own ZFS apart from ZoL because one day ZoL will be a catastrophic failure waiting to happen.

I agree with this, even if ZoL doesn't screw up. Mostly because FreeBSD will become a second class citizen again. It will always be the one catching up.
ZoL will probably also do something weird like tie ZFS to systemd/Linux cgroups making it a big faff to maintain a portable patchkit.

I personally would prefer an "out-of-date" but rock solid "native" implementation of ZFS.

But ultimately it is up to the FreeBSD developers. ZFS is massive so I can understand why they want to pass on some of the maintenance burden to an external project.
 
From my limited understanding the big complaint with init is that it can't load processes in parallel. Seems to me like a small justification for replacing it with something largely more complicated, more monolithic, and more prone to issues (aside from its poorly written code). So what's the big advantage, some milliseconds saved at boot?

Well I'm also not a systemd aficionado but my understanding is also that it is/was their main motivation. Of course this is based on their main demographic being those who constantly reboot, apparently. For servers, who cares how long they take to boot because if the system is stable and reliable that should happen rarely if ever.

I too cannot understand complicating a simple process for the sake of seconds saved in booting. Just use an SSD or stop loading unnecessary daemons at the start. When you look at some of the Linux distributions, no wonder they want faster and parallel boots, they load so many useless programs it's mind blowing.
 
Status
Not open for further replies.
Back
Top