Linus: Don't Use ZFS • Hacker News Board

Re: Linus: Don't Use ZFS

#91

Post by shawnz » Thu, Jan 09, 2020, 9:46 PM UTC

xupybd wrote: post #28

reacharavindh wrote: post #10

As a heavy user of ZFS and Linux, what else is there that even comes close to what ZFS offers? I want cheap and reliable snapshots, export & import of file systems like ZFS datasets, simple compression, caching facilities(like SLOG and ARC) and decent performance.

I agree that ZFS has a lot to offer. But the legal difficulties in merging ZFS support into the mainline kernal are understandable. It's a shame but I think he is making the right call.

Merging into the mainline kernel is not what the person he is replying to was even asking for. All they were asking is for Linux to stop putting APIs behind DRM that prevents non-GPL modules like ZFS from using them. That doesn't mean ZFS must be bundled with Linux.

I think everyone is in agreement that ZFS can't be included in the mainline kernel. The question is just if users should be able to install and use it themselves or not.

Re: Linus: Don't Use ZFS

#92

Post by AtHeartEngineer » Thu, Jan 09, 2020, 9:46 PM UTC

montjoy wrote: post #83

reacharavindh wrote: post #10

As a heavy user of ZFS and Linux, what else is there that even comes close to what ZFS offers? I want cheap and reliable snapshots, export & import of file systems like ZFS datasets, simple compression, caching facilities(like SLOG and ARC) and decent performance.

Hardware RAID controllers can do most if not all of these things.

The problem with most of these is you have to bring the system down to do maintenance. You can do a scrub on zfs while it's up.

Re: Linus: Don't Use ZFS

#93

Post by dang » Thu, Jan 09, 2020, 9:52 PM UTC

kirstenbirgit wrote: post #74

Linus should stick to his kernel and git. It feels like he has very little knowledge about computing outside of those areas. That would also make his abrasive way of communicating easier to tolerate. He mostly comes across as the typical autistic savant type that's great at an extremely specific area, but only that.

No personal attacks on HN, please. Maybe you don't owe Linus better (though why not?), but you owe the community better if you want to post here.

Also, "typical autistic savant type" breaks the site guideline against calling names. Please don't do that.

https://news.ycombinator.com/newsguidelines.html

Edit: you've unfortunately been doing this repeatedly:

https://news.ycombinator.com/item?id=21889883

https://news.ycombinator.com/item?id=21089837

Can you please not? Making an account to be anonymous on HN is fine in principle, but people sometimes start breaking the rules after they do so, and that is not cool.

Re: Linus: Don't Use ZFS

#94

Post by Nullabillity » Thu, Jan 09, 2020, 9:52 PM UTC

Wowfunhappy wrote: post #70

Jonnax wrote: post #4

Here's his reasoning: "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…

> 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…

> 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 corporative vendors sometimes have NDAs which preclude releasing open source drivers.

Nvidia is pretty much the only remaining holdout here on the hardware driver front. I don't see why they should get special treatment when the 100%-GPL model works for everyone else.

Re: Linus: Don't Use ZFS

#95

Post by Wowfunhappy » Thu, Jan 09, 2020, 9:52 PM UTC

cryptonector wrote: post #90

Wowfunhappy wrote: post #70

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…

ZFS is not really GPL-incompatible either, but it doesn't matter. Between FUD and Oracle's litigiousness, the end result is that there is no way to overcome the impression that it is GPL-incompatible. But it is a problem that you can't reliably have out-of-tree modules. Also, Linus is wrong: there's no reason that the ZoL project can't keep the ZFS module in working order, with some lag relative to updates to the Lin…

> But it is a problem that you can't reliably have out-of-tree modules.

That is the bit I'm trying to get at. Yes it would be best if ZFS was just part of Linux, and maybe some day it can be after Oracle is dead and gone (or under a new leadership and strategy). But it's almost beside the point.

Every other OS supports installing drivers that aren't "part" of the OS. I don't understand why Linux is so hostile to this very real use case. Sure it's not ideal, but the world is full of compromises.

Re: Linus: Don't Use ZFS

#96

Post by atemerev » Thu, Jan 09, 2020, 9:52 PM UTC

Do you know that FreeBSD is actually a usable modern OS these days? ;) I run a FreeBSD desktop with Nvidia drivers without any issues. OpenJDK works great, among other things. And it supports ZFS natively, and root on ZFS is the default installation option.

Re: Linus: Don't Use ZFS

#97

Post by ants_a » Thu, Jan 09, 2020, 9:52 PM UTC

bbatha wrote: post #82

maximente wrote: post #58

i wouldn't use ZFS either. my guess is 90% of ZFS users have never run failure scenarios and grappled with potential failure modes of ZFS, nor even know that you really need ECC RAM to run ZFS without fear of existential data corruption due to bit flips. furthermore, the allure of ZFS means people aren't testing their disaster plans until it's too late, bc ZFS is "resilient". lastly, data recovery is expensive as all…

> you really need ECC RAM to run ZFS This is FUD. ZFS does as well, if not better than the average file system with its focus on integrity, online scrubs etc. On the other hand "use ECC RAM" is standard best practices for any mission critical data, no file system magic is going to fix computer RAM lying to you 100% of the time. Its the standard recommendation for ZFS because its rare to be deployed in environments th…

I've detected broken memory chips thanks to BTRFS checksumming finding errors, luckily before it had a chance to corrupt any written data. So if anything, a properly checksummed filesystem makes non-ECC RAM less dangerous.

Re: Linus: Don't Use ZFS

#98

Post by aseipp » Thu, Jan 09, 2020, 9:53 PM UTC

jessant wrote: post #33

fgonzag wrote: post #25

Earlier quoted context omitted.

Bcachefs is probably the only thing that will get there. The codebase is clean and we'll mantained, built from solid technology (bcache) and will include most of the ZFS niceties. I just wish more companies would sponsor de project and stop wasting money on BTRFS

Snapshots don't seem to be done yet.

Kent has admitted (many times) that snapshots are one of the more difficult features to add in a reliable and safe way, and will require significant work to do right, especially for what he wants to see them do (I assume "really damn fast and low overhead" is a major one, plus some other tricks he has up his sleeve.) So he has intentionally not tackled them yet, instead going after a slew of other features first. Reflink, full checksum, replication, caching, compression, native encryption, etc. All of that works today.

Snapshots are a huge feature for sure, but it's not like bcachefs is completely incapable without them.

There was a very recent update he gave in late December (2019) that mentioned he's actively chipping away at the roadblocks for snapshots.

Re: Linus: Don't Use ZFS

#99

Post by streb-lo » Thu, Jan 09, 2020, 9:54 PM UTC

Wowfunhappy wrote: post #87

rumanator wrote: post #85

Earlier quoted context omitted.

> 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. The problem is already addressed: if someone wants to contribute code to the project then it's licensing must be compatible with the prior work contributed to project. That's it.

But why are all drivers expected to be "part of the project"? We don't treat userspace Linux software that way. We don't consider Windows drivers part of Windows.

Because running proprietary binaries in kernel space is not a good idea nor is it compatible with the vision of Linux?

Re: Linus: Don't Use ZFS

#100

Post by puzzledobserver » Thu, Jan 09, 2020, 9:54 PM UTC

gh123man wrote: post #77

Wowfunhappy wrote: post #70

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…

I am also not an expert in this space - but if I understand correctly the reason the linux Nvidia driver sucks so much is that it is not GPL'd (or open source at all). There is little incentive for Nvidia to maintain a linux specific driver, but because it is closed source the community cannot improve/fix it. > Why are all drivers expected to use the GPL? I think the answer to this is: drivers are expect to use the G…

I would expect a large fraction of Nvidia's GPU sales to be from customers wanting to do machine learning. What platform do these customers typically use? Windows?

How do the Linux and Windows drivers compare on matters related to CUDA?