Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus: Don't Use ZFS

realworldtech.com

Post reply on HN
Print view View original

81–90 of 571 posts

Re: Linus: Don't Use ZFS

#81

Post by montjoy »

rleigh wrote: post #24
Covzire wrote: 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?"

Not sure where that belief comes from. But it might be that many benchmarks are naive and compare it against other filesystems in single-disc setups with zero tuning. Since its metadata overheads are higher, it's definitely slower in this scenario. However, put a pool onto an array of discs and tune it a little, and the performance scales up and up leaving all Linux-native filesystems, and LVM/dm/mdraid, well behind.…

Last time I used ZFS write performance was terrible compared to an ordinary RAID5. IIRC Writes in a raidz are always limited to a single disk’s performance. The only way to get better write speed is to combine multiple raidzs - which means you need a boatload if disks.

Re: Linus: Don't Use ZFS

#82

Post by bbatha »

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 that can tolerate data corruption.

> pathologically backing it up and testing said backups.

ZFS doesn't remove the need for backups and no one seriously makes that arguments. Though snapshots + send/receive make them very easy to do in ZFS.

Re: Linus: Don't Use ZFS

#83

Post by montjoy »

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.

Re: Linus: Don't Use ZFS

#84

Post by tjoff »

bayindirh wrote: post #57
znpy wrote: post #48

Earlier quoted context omitted.

people probably will, in a few years. rotational disks are getting cheaper and cheaper, 10TB disks in two years might cost as little as 2TB disks today (i got a 2TB disk for like 50€ off Amazon).

> people probably will, in a few years. Yes, but without the array as you stated. We have 300+ 10TB disks at our datacenter today and, ZFS is relevant at this disk count, I/O and client load. Running ZFS at small scale is raising a cow at home for a bucket of raw milk. It's more of a fun curiosity rather than a production level operation. I'd run LVM or md or something similar at home instead of a full blown ZFS setu…

I feel ZFS are much better and easier than md or LVM. At least had it been properly supported (I have never tried ZoL).

CoW and cheap snapshots are game-changers, checksums as well but maybe not from a practicality and home-user standpoint. This holds just as well on PB storage as a 512 GB OS drive as a 2 GB thumb-drive (not that I would use ZFS on a thumb drive - again because of proper support across different OS).

Re: Linus: Don't Use ZFS

#85

Post by rumanator »

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…

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

Re: Linus: Don't Use ZFS

#86

Post by 0x8BADF00D »

Honestly ext4 is fine for most use cases, even SSDs. If you really need more performance look at HAMMER, it’s meant for high availability. At that point you shouldn’t be running Linux anyway, even with RT_PREEMPT it’s not going to be the most performant for those kinds of RTOS workloads anyway.

Re: Linus: Don't Use ZFS

#87

Post by Wowfunhappy »

rumanator wrote: post #85
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…

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

Re: Linus: Don't Use ZFS

#88

Post by organsnyder »

btilly wrote: post #35
Hamuko wrote: post #7

Earlier quoted context omitted.

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

Here are his reasons for generally avoiding ZFS from what I consider most important to least. - The kernel team may break it at any time, and won't care if they do. - It doesn't seem to be well-maintained. - Performance is not that great compared to the alternatives. - Using it opens you up to the threat of lawsuits from Oracle. Given history, this is a real threat. (This is one that should be high for Linus but not…

A former employer was threatened by Oracle because some downloads for the (only free for noncommercial use) VirtualBox Extension Pack came from an IP block owned by the organization. Home users are probably safe, but Oracle's harassment engine has incredible reach.

Re: Linus: Don't Use ZFS

#90

Post by cryptonector »

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…

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 Linux mainline, so as long as you stay on supported kernels and the ZoL project remains alive, then of course you can use ZFS. And you should use ZFS because it's awesome.

Post reply on HN