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

161–170 of 571 posts

Re: Linus: Don't Use ZFS

#161

Post by esoterae »

wazoox wrote: post #130
HorstG wrote: post #107

Earlier quoted context omitted.

We had a bunch of Thumpers (SunFire X4200) with 48 disks at work, running ZFS on Solaris. It was dog slow and awful, tuning performance was complicated and took ages. One had to use just the right disks in just the right order in RaidZs with striping over them. Swap in a hotspare: things slow to a crawl (i.e. not even Gbit/s). After EoL a colleague installed Linux with dmraid, LVM and xfs on the same hardware: much f…

ZFS performs quite well if you give it boatloads of RAM. It uses its own cache layer, and eats RAM like hotcakes. XFS OTOH is as fast as the hardware can go with any amount of RAM.

Sort of. But no snapshots.

Wanna use LVM for snapshots? 33% performance hit for the entire LV per snapshot, by implementation.

ZFS? ~1% hit. I've never been able to see any difference at the workloads I run, whereas with LVM it was pervasive and inescapable.

Re: Linus: Don't Use ZFS

#162

Post by stock_toaster »

zelly wrote: 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.

> ZFS hasn't kept up with SSDs.

Pretty sure this is false. ZFS does support trim (FreeBSD had trim support for quite a while, but ZoL has it now as well), as well as supporting l2arc and zil/slog on ssd.

> ZFS partitions are also almost impossible to resize

You can grow zfs partitions just fine (and even online expand). You just can't shrink them.

Re: Linus: Don't Use ZFS

#163

Post by SignalsFromBob »

alperakgun wrote: post #145
phyzome wrote: post #89

Until I have a viable alternative that gives me snapshotting (so I can make consistent backups), that advice is worthless to me.

in the application-level, snapshotting is not a way to do "consistent backup"s . consistent backup is a backup with a planned or known state when "restore"ing.

Sure it is. Quiesce your application, take a snapshot, then resume application. Then you can back up the snapshot. The alternative can be a lengthy downtime for your application.

Re: Linus: Don't Use ZFS

#164

Post by DSMan195276 »

derefr wrote: post #135
DSMan195276 wrote: post #108

Earlier quoted context omitted.

It's pretty simple, once they expose such an API they'd have to support it forever, hindering options for refactoring (that happens all the time). With all the drivers in the tree, they can simply update every driver at the same time to whatever new in-kernel API they're rolling out or removing. And being that the majority of drivers would arguably have to be GPL anyway, and thus open-source, the advantages of keepin…

You know, come to think of it, is there anything stopping Linux from having a... FKSE (Filesystem in Kernel SpacE) standard API? Presumably, such a thing would just be a set of kernel APIs that would parallel the FUSE APIs, but would exist for (DKMS) kernel modules to use, rather than for userland processes to use. Due to the parallel, it would only be the work of a couple hours to port any existing FUSE server over…

I mean, it doesn't really work that way, you can't just port a userspace program into a kernel module. For starters, there's no libc in the kernel - what do you do when you want to call `malloc`? ;)

With that, I doubt the performance issues are directly because it runs in userspace, they're likely due to the marshaling/transferring from the in-kernel APIs into the FUSE API (And the complexity that comes with talking to userspace for something like a filesystem), as well as the fact that the FUSE program has to call back into the kernel via the syscall interface. Both of those things are not easily fixable - FKSE would still effectively be using the FUSE APIs, and syscalls don't translate directly into callable kernel functions (and definitely not the ones you should be using).

Re: Linus: Don't Use ZFS

#165

Post by HorstG »

__jal wrote: post #134
HorstG wrote: post #107

Earlier quoted context omitted.

We had a bunch of Thumpers (SunFire X4200) with 48 disks at work, running ZFS on Solaris. It was dog slow and awful, tuning performance was complicated and took ages. One had to use just the right disks in just the right order in RaidZs with striping over them. Swap in a hotspare: things slow to a crawl (i.e. not even Gbit/s). After EoL a colleague installed Linux with dmraid, LVM and xfs on the same hardware: much f…

Sounds like you turned on dedupe, or had an absurdly wide stripe size. You do need to match your array structure to your needs as well as tune ZFS. On our backup servers (45 disks, 6-wide Z2 stripes) easily handle wire-speed 10G with 32G ARC. And you're just wrong about snapshots and filesystem counts. ZFS is no speed demon, but it performs just fine if you set it up correctly and tune it.

Stripe size could have been a problem, though we just went with the default there afair. Most of the first tries was just along the Sun docs, we later only changed things until performance was sufficient. Dedupe wasn't even implemented back then.

Maybe you also don't see as massive an impact because your hardware is a lot faster. X4200s were predominantly meant to be cheap, not fast. No cache, insufficient RAM, slow controllers, etc.

Re: Linus: Don't Use ZFS

#166

Post by liuliu »

pizza234 wrote: post #132
btilly wrote: post #35

Earlier quoted context omitted.

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…

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

Re: Linus: Don't Use ZFS

#167

Post by stock_toaster »

m0zg wrote: post #46
blibble wrote: post #2

I'll give up Linux on my servers before I give up ZFS especially so given the recent petulant attitude that broke API compatibility in the LTS branch just to spite the ZFS developers: https://news.ycombinator.com/item?id=20186458 compete honestly on technical merit, rather than pulling dirty tricks that you'd expect of Oracle or 1990's MS

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…

> Oracle should consider GPL-ing it and integrating it into Linux directly

I think Apache (or BSD/MIT) would be far more palatable, as GPL'ing it would cut off the BSDs as well as OpenSolaris, which would certainly be a bummer.

Re: Linus: Don't Use ZFS

#168

Post by throwaway6779 »

shawnz wrote: post #137
spinningslate wrote: post #131

Earlier quoted context omitted.

Can you expand? I'm no expert - use linux daily but have always just used distro default file system. Linus' reasons for not integrating seems pretty sensible to me. Oracle certainly has form on the litigation front.

Linus' reasons for not integrating ZFS are absolutely valid and it's no doubt that ZFS can never be included in the mainline kernel. There's absolutely no debate there. However the person he is replying to was not actually asking to have ZFS included in the mainline kernel. As noted above, that could never happen, and I believe that Linus is only bringing it up to deflect from the real issue. What they were actually…

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

Re: Linus: Don't Use ZFS

#169

Post by zAy0LfpBZLC8mAC »

derefr wrote: post #135
DSMan195276 wrote: post #108

Earlier quoted context omitted.

It's pretty simple, once they expose such an API they'd have to support it forever, hindering options for refactoring (that happens all the time). With all the drivers in the tree, they can simply update every driver at the same time to whatever new in-kernel API they're rolling out or removing. And being that the majority of drivers would arguably have to be GPL anyway, and thus open-source, the advantages of keepin…

You know, come to think of it, is there anything stopping Linux from having a... FKSE (Filesystem in Kernel SpacE) standard API? Presumably, such a thing would just be a set of kernel APIs that would parallel the FUSE APIs, but would exist for (DKMS) kernel modules to use, rather than for userland processes to use. Due to the parallel, it would only be the work of a couple hours to port any existing FUSE server over…

The hard part isn't the "FKSE API", the hard part is for the "FKSE driver" to be able to do anything other than talk to that API. Like, scheduling, talking to storage, the network, whatever is needed to actually implement a useful filesystem.

Re: Linus: Don't Use ZFS

#170

Post by shawnz »

throwaway6779 wrote: post #168
shawnz wrote: post #137

Earlier quoted context omitted.

Linus' reasons for not integrating ZFS are absolutely valid and it's no doubt that ZFS can never be included in the mainline kernel. There's absolutely no debate there. However the person he is replying to was not actually asking to have ZFS included in the mainline kernel. As noted above, that could never happen, and I believe that Linus is only bringing it up to deflect from the real issue. What they were actually…

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.
Post reply on HN