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

111–120 of 571 posts

Re: Linus: Don't Use ZFS

#111

Post by forgotpwd16 »

fgonzag wrote: post #25
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.

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

>stop wasting money on BTRFS

You're saying they should stop supporting a project that was considered stable by the time the other started being developed. Why do that? What makes Bcachefs a better choice?

Re: Linus: Don't Use ZFS

#112

Post by HorstG »

voltagex_ wrote: post #44
rleigh wrote: post #24

Earlier quoted context omitted.

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

Have you got any info on how to do the required tuning that's geared towards a home NAS?

Group your disks in bunches of 4 or 5 per Raidz, no more. And have them on the same controller or SAS-expander per bunch. Use striping over the bunches. Don't use hotspares, for performance maybe avoid RAIDz6. Try out and benchmark a lot. Get more RAM, lots more RAM.

Re: Linus: Don't Use ZFS

#113

Post by [deleted] »

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…

[deleted]

Re: Linus: Don't Use ZFS

#114

Post by rubyn00bie »

Or do use ZFS, just know that Oracle sucks and you have to go through hoops because of it...

Also, while ZFS for me has been performant, that seems like a silly reason to decide to use it or not use it. I think ZFS pools and snapshots would be among the deciding factors to use it or not.

FWIW, as some other commenters have said, I'd rather drop Linux than drop ZFS. I'm actually only even running Linux on my home server right now because I decided to try Proxmox out on it months ago and it was soooo obscenely easy to install I haven't bothered to reset it yet (though I need to for various reasons; Proxmox itself being the first, ha).

Really all I care about for my host OS these days is the ability to do virtualization and GPU pass-through... Linux is an option but not the only one. Having a robust storage system where drives can fail, exist as one logical drive, are replicated, has snapshots (including RAM), and I literally don't have to worry about it-- that though, that's really only available with ZFS.

Re: Linus: Don't Use ZFS

#115

Post by jandrese »

rleigh wrote: post #101
jandrese wrote: post #60

Earlier quoted context omitted.

API Infringement.

That's not even a thing (yet). ZFS was freely relicensed under the CDDL by Sun. Oracle can do nothing to take back any of the rights granted under the terms of the licence retrospectively. They haven't got any grounds whatsoever to curtail anyone's use or modification of the ZFS code.

It's been a thing for a decade[1] now. If you don't have a Google-sized team of lawyers handy it's a concern. Fingers crossed that Oracle loses in the end.

[1] https://en.wikipedia.org/wiki/Google_v._Oracle_America

Re: Linus: Don't Use ZFS

#116

Post by ordu »

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.

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

It is the policy of linux development at work. Linux kernel doesn't break userspace, you could safely upgrade kernel, your userspace would work nice. But Linux kernel breaks inner APIs easily, and kernel developers take responsibility for all the code. So if a patch in memory management subsystem broke some drivers, kernel developers would find breakages and fix them.

> We don't consider Windows drivers part of Windows.

Yeah, because Windows kernel less frequently breaks backward compatibility in kernel space, and because hardware vendors are ready to maintain drivers for Windows.

Re: Linus: Don't Use ZFS

#117

Post by fgonzag »

forgotpwd16 wrote: post #111
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

>stop wasting money on BTRFS You're saying they should stop supporting a project that was considered stable by the time the other started being developed. Why do that? What makes Bcachefs a better choice?

Take a cursory look into both codebases, the stability of the every feature at launch and on maintenance. It's not hard to see BTRFS is a doomed project. Bcachefs is more like PostgreSQL, the developer doesn't add features until he has a solid design that's well thought out. Hence why he hasn't implemented snapshots.

I don't think too many people consider it stable enough for production, either. (Unless you count a very limited subset of its functionality).

I rather run Bcachefs today than Btrfs, by a mile. At least with bcachefs I won't lose my data.

Re: Linus: Don't Use ZFS

#118

Post by HorstG »

AtHeartEngineer wrote: post #92
montjoy wrote: post #83

Earlier quoted context omitted.

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.

Most non-hobbyist RAID hardware does online-scrub just fine (not that I would recommend wasting money on such hw).

Btw, ZFS scrub is not only a RAID-block-check but also a partial fsck, so its not really comparable.

Re: Linus: Don't Use ZFS

#119

Post by rumanator »

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.

You can license both kernel modules or FUSE implementation any way you see fit. That's a non-issue.

https://www.kernel.org/doc/html/latest/process/license-rules...

It seems that some people are oblivious to the actual problem, which is some people want their code to be mixed into the source code of a software project without having to comply with the rightholder's wishes, as if their will shouldn't be respected.

> We don't consider Windows drivers part of Windows.

I'm not sure you can commit your source code to the windows kernel project.

Re: Linus: Don't Use ZFS

#120

Post by berbec »

dsr_ wrote: post #51
bayindirh wrote: post #29

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.

The one thing I can't understand about btrfs is the unknown answer to the question "How much disk space do I have left?". I don't get that being a "this much, maybe" answer
Post reply on HN