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

301–310 of 571 posts

Re: Linus: Don't Use ZFS

#301

Post by yjftsjthsd-h »

shmerl wrote: post #257
yjftsjthsd-h wrote: post #23

Alright, Linus, I'll make you a deal: I'll consider dropping ZFS when you ship a production-grade BTRFS (or reiserfs or anything else with the same features).

bcachefs is aiming to replace btrfs.

Yep:) I'd forgotten about that one, but when it gets merged I will have to seriously consider it! Unfortunately, that's probably years out, so I'm stuck on ZFS for now. I also have some portability concerns (ZFS works on FreeBSD, NetBSD, Illuminos, and Linux, and this was a selling point for me), but I'll probably get over it or at least mostly switch to bcachefs when it goes mainline.

Re: Linus: Don't Use ZFS

#302

Post by dathinab »

rumanator wrote: post #119
Wowfunhappy wrote: post #87

Earlier quoted context omitted.

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…

No, no one wants to force ZFS into the Linux kernel. I think anyone agrees that it needs to be out-of tree the way thinks are currently.

The problem is the nature of changes, and people questioning if there is any good _technical_ reason why some of the changes need to be the way they are done.

Re: Linus: Don't Use ZFS

#303

Post by dathinab »

ttttttttttt- wrote: post #278
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. As a Linux user and an ex android user, I absolutely disagree and would add that the GPL requirement for drivers is probably the biggest feature Linux has!

Yes, the often times proprietary android linux driver for are such a pain. Not only make they it harder to reuse the hardware outside of android (e.g. in a laptop or similar). But they also tend to cause delays with android updates and sometimes make it impossible to update a phone to a newer android version even if the phone producer wants to do so.

Android did start making this less of problem with HAL and stuff, but it's still a problem, just a less big one.

Re: Linus: Don't Use ZFS

#304

Post by jeltz »

ac29 wrote: post #295
liuliu wrote: 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

Many of the advanced features aren't implemented yet though, like compression, encryption, snapshots, RAID5/6....

Compression and encryption have been implemented, but not snapshots and RAID5/6.

Re: Linus: Don't Use ZFS

#305

Post by stock_toaster »

chungy wrote: post #239
stock_toaster wrote: post #162

Earlier quoted context omitted.

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

> You just can't shrink them. That's not even entirely true, though it requires shuffling around with multiple vdevs temporarily and doesn't presently support raidz. Also vdev removal is primarily made to support an accidental "oops, I added a disk I shouldn't have" rather than removing a long-lived device -- there's no technical restriction against the later case, though the redirect references could hamper performa…

yup, true enough. You can accomplish great things with a combination of zfs send/receive and time. ;)

Re: Linus: Don't Use ZFS

#306

Post by spamizbad »

lizknope wrote: post #293
admax88q wrote: post #277

Earlier quoted context omitted.

> We've wasted enough effort over obscure licensing minutia. Which was precisely Sun/Oracle's goal when they released ZFS under the purposefully GPL incompatible CDDL. Sun was hoping to make OpenSolaris the next Linux whilst ensuring that no code from OpenSolaris could be moved back to linux. I can't think of another plausible reason why they would write a new open source license for their open source operating syste…

https://en.wikipedia.org/wiki/Common_Development_and_Distrib... Some people argue that Sun (or the Sun engineer) as creator of the license made the CDDL intentionally GPL incompatible.[13] According to Danese Cooper one of the reasons for basing the CDDL on the Mozilla license was that the Mozilla license is GPL-incompatible. Cooper stated, at the 6th annual Debian conference, that the engineers who had written the S…

Wow... talk about cutting off your nose to spite your face. Oracle ended up abandoning OpenSolaris within a year or so.

Edit: Nevermind, debunked by Bryan Cantrill. It was to allow for proprietary drivers.

Re: Linus: Don't Use ZFS

#307

Post by prakhunov »

sterlind wrote: post #285
celticmusic wrote: post #177

Earlier quoted context omitted.

My experience is that linux nvidia drivers are better than the competitors open source drivers.

Nvidia proprietary drivers work OK for me, mostly (I needed to spoof the video card ID so KVM could lie to the Windows drivers in my home VFIO setup, but it wasn't hard.) But it means I can't use Wayland. Wayland isn't critical for me, but since NVidia is refusing to implement GBM and using EGLStream instead, there's nothing I can do about it. It simply isn't worth NVidia's time to make Wayland work, so I'm stuck usi…

No you can use Wayland as long as your window manager/environment supports GBM. Gnome and KDE both do (Which for most Linux users is all that is needed).

Now you can't use something like Sway but their lead developer is too evangelical for my taste so even if I had an AMD/Intel card I would never use it.

Re: Linus: Don't Use ZFS

#308

Post by kjs3 »

paulmd wrote: post #297
kjs3 wrote: post #264

Earlier quoted context omitted.

Yeah...I use FreeBSD for file servers because I don't have to even pay attention this constant ZFSonLinux drama. I treat them like almost like appliances. Linux servers are more than happy to use them on the back-end.

how do you structure that? block images served by iscsi? shares served by nfs/samba?

All of the above, depending on what I'm trying to accomplish. Usually Samba for Windows clients and general bulk storage (pretty much everything can do CIFS mounts at some basic level these days), NFS for *nix and VMWare clients (esp where I can leverage NFSv4), iSCSI for various block image needs, scp/sftp/rsync. All of this is basic out of box for FreeBSD.

In operations, I treat them as semi-black-box (grey-box?) appliance where they only do the file storage function and are moral equivalents of Network Appliance NAS boxes. I don't try to convince the Linux or Windows teams to migrate other workloads to FreeBSD, and mostly don't want them to since that would mean Yet Another app environment to support.

FreeBSD has a really efficient network stack, so I can attach the FreeBSD stores at 10GB (usually, 2-4 bonded 10GB links) and it keeps up fine. I I have colleagues who are doing the same with 40GB links (40-160BG aggregate) to backbone networks, and apparently there are many shops hooking up FreeBSD with 100GB links. Limiting factor seems to be ZFS and the storage subsystems supporting it, not network, which is interesting, but I don't have the ability to benchmark the 40GB and higher stuff.

Re: Linus: Don't Use ZFS

#309

Post by shawnz »

tylerl wrote: post #265
shawnz wrote: post #122

Earlier quoted context omitted.

None of these are good reasons to purposely hinder the optional use of ZFS as a third party module by users, which is what Linux is doing.

This want a case of "purposely hinder", but rather the zfs nodule broke because of some kernel changes. The kernel is careful to never break userspace and never break its own merged modules. But if you're a third-party module then you're on your own. The kernel developers can't be responsible for maintaining compatibility with your stuff.

The changes conveniently accomplished nothing except for breaking ZFS. Furthermore, just because they don't officially support ZFS doesn't mean they must stonewall all the users who desire the improved compatibility. Reverting this small change would not be a declaration that ZFS is officially supported.

Re: Linus: Don't Use ZFS

#310

Post by zamalek »

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…

> ZFS has a CDDL license

Java is GPLv2+CPE. That didn't stop Oracle because, as Linus pointed out in the email, Oracle regards their APIs as a separate entity to their code.

Post reply on HN