Live data from Hacker News

Linus: Don't Use ZFS

realworldtech.com

321–330 of 571 posts

Re: Linus: Don't Use ZFS

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

Btrfs crashed for me on two occations, last time, around 2 years back I have installed zfs (which I am using for ~10 years on FreeBSD server) which works like a charm since then.

I understand Linus reasoning but there is just no way I will install btrfs, like ever. I rather dont update kernel (I am having zfs on fedora root with degular kernel updates and scripts which verify that everything is with kernel modules prior to reboot) than use file system that crashed twice in two years.

Yes it is very annoying if update crashes fs, but currently:

- in 2 years two time btrfs crashed itself

- in next 2 years update never broke zfs

As far as I am concerned, the case for zfs is clear.

This might be helpful to someone: https://www.csparks.com/BootFedoraZFS/index.md

Anyway Linus is going too far with his GPL agenda, the MODUL_LICENSE writting kernel moduls explains why the hardware is less supported on linux - instead of devs. focusing on more support from 3rd party companies, they try to force them to do GPL. Once you set MODUL_LICENSE to non GPL, you quickly figure out that you can't use most of kernel calls. Not the code. Calls.

Re: Linus: Don't Use ZFS

#322
post #51

Earlier quoted context omitted.

Honestly asking, how Btrfs compares to ZFS? There's also Lustre but it's a different beast altogether for a different scenario.

On the surface, btrfs is pretty close to zfs. Once you actually use them, you discover all the ways that btrfs is a pain and zfs is a (minor) joy: - snapshot management - online scrub - data integrity - disk management I lost data from perfectly healthy-appearing btrfs systems twice. I've never lost data on maintained zfs systems, and I now trust a lot more data to zfs than I ever have to btrfs.

btrfs is such a mess that for a database or VM to be marginally stable, you have to disable the CoW featureset for those files with the +C attribute. It's nowhere near a serious solution.

Re: Linus: Don't Use ZFS

#323
post #212
post #166

Earlier quoted context omitted.

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?

To my knowledge, caching layers are supported but require some setup and don't have much documentation to setup rn.

If all you need is a simple root FS that is CoW and checksummed, bcachefs works pretty good, in my experience. I've been using it productively as a root and home FS for about two years or so.

Re: Linus: Don't Use ZFS

#324
post #220
post #41

Earlier quoted context omitted.

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.

Plenty of drivers get rejected because the kernel developers have no confidence that they will be maintained going forward, which would mean the driver would be removed fairly quickly again.

Re: Linus: Don't Use ZFS

#325
post #84

Earlier quoted context omitted.

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

What about the performances, is ZFS in the same ballpark than an equivalent (data-protection-wise) 'md' layout?

Re: Linus: Don't Use ZFS

#327
Don't go too far people. Linus's criticism against ZFS is concise: buzzword & licensing.

Here, Linus is putting emphasis on license, not technical whatever details of ZFS. He clearly doesn't use ZFS and is not even interested in the problem ZFS solves. He is only "interested" is his (and community's) control over the ZFS source code.

So, his logic basically becomes this:

ZFS is not mainline-able, so veto it until Oracle changes its attitude - a simple old FOSS infestation tactic.

So, please, move on, people. The discussion is not even about file system...

Re: Linus: Don't Use ZFS

#328
post #189
post #84

Earlier quoted context omitted.

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

Checksums are amazing for when you do have a problem, because a scrub will tell you what you lost. Knowing what's been damaged is practically more important then actually fixing it, and ZFS is great at this. All the Linux alternatives answers to this problem are always "is your data okay? Don't know! It'll be a surprise when you get there".

I know, and personally that is very important for me.

But in practice, it is likely to be less than once in a decade problem - and you should have backups anyway.

So I can understand someone having different priorities. (not me though, data integrity is as important as it gets, I'd gladly pay performance/money for it)

Re: Linus: Don't Use ZFS

#329
post #25

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.

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

>Bcachefs is probably the only thing that will get there.

Or Bcachefs is probably the only thing that might get there.

The amount of engineering hours went into ZFS is insane. It is easy to get a project that has 80% similarity on the surface, but then you spend the same amount of time from 0 - 80% on the last 20% and edge cases. ZFS has been battle tested by many. Rsync is on ZFS.

The amount of Petabyte stored in ZFS safely over the years gives peace of mind.

Speaking of Rsync, normally a topic of ZFS on HN will have him resurface. Hasn't seen any reply from him yet.

Re: Linus: Don't Use ZFS

#330
post #153

I don't blame Linus, but I use ZFS a lot. I'll drop ZFS the moment I have an alternative with the same features: - disk management with simple commands that can create raids in any modern configuration - zero cost snapshots - import/export (zfs send/recv) - COW and other data integrity niceties - compression, encryption, dedup, checksums I am very grateful to the OpenZFS community, and I think they deserve praises fo…

So why drop ZFS then?
Post reply on HN