The potential risk to ZFS created by the shift in its userbase

Re:The potential risk to ZFS created by the shift in its use... by pierrebai on Monday January 28, 2019 @11:40AM (#19018834)

In the context of Linus stance that the kernel must never, ever break userland, I find it strange that he has not slapped the change of a function to GPL-only callers as incorrect and reverted it.

You have a policy that you can't break users' programs, but borking their whole file-system is fine? Keep feeding end-users fears of open source petty feuds making people miserable. That works.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by chaosite on Monday January 28, 2019 @11:45AM (#19018891)

Because... That's not userspace, that's kernelspace. Linux's policy on kernelspace API breakage is famously, "we do what we like, and if you're not in-kernel, then you get to keep both pieces when it breaks".

If ZFS wanted to live in userspace (and get Linux's userspace API guarantees) then they could have made a FUSE filesystem instead.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by DiabloD3 on Monday January 28, 2019 @12:56PM (#19019490)

ZFS-FUSE existed before ZoL did. The reason they moved to their SPL-based solution is because FUSE didn't want to make the required changes to support high performance file systems.

SPL now handles the guarantee to separate ZFS's userland components from Linux's constant internal kernelspace API churn. ZFS, internally, doesn't really know what a Linux is beyond a few little bits here and there.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by Conan_Kudo on Monday January 28, 2019 @10:35PM (#19023511)

> ZFS-FUSE existed before ZoL did. The reason they moved to their SPL-based solution is because FUSE didn't want to make the required changes to support high performance file systems.

These changes were made years later, but the developer of ZFS-FUSE disappeared, so they were never used.

The FUSE v3 API further builds on that, and today, it's definitely possible to build a high-performance filesystem using FUSE. In fact, there are many examples of this in the wild: GlusterFS, Ceph, NTFS-3G, and so on.

Today, there's absolutely _no_ reason ZFS would not sensibly work as high performance filesystem entirely from userspace. In fact, it still remains an open issue and a desirable target for ZoL: https://github.com/zfsonlinux/zfs/issues/8

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by kzrdude on Monday January 28, 2019 @01:13PM (#19019651)

That sounds like a missed opportunity, who doesn't want higher performance fuse filesystems?

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by ianschenck on Monday January 28, 2019 @06:54PM (#19022347)

Glad you brought this up. It feels, at least to me, like FUSE is only for...hmm...gimmick or science-fare projects. Maybe something useful on your development machine. Indeed, at a previous employer, several problems were addressed using a handful of FUSE filesystems, quite elegantly. Of course the caveat was "this ain't prod, duh, it's FUSE". But this doesn't NEED to be the case. Tangentially, microkernels pop up here often, and arguable, moving some filesystems to user space makes sense in a related vein.

I'll admit, I'm all talk and if it really mattered, pull requests are probably welcome.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by pierrebai on Monday January 28, 2019 @05:01PM (#19021499)

You're confirming what I just said.

End-user dont'care about splitting hairs. Iwas using Linux in the mid-90's and that kind of stance is what turned me off. The sound card would brek, the networking would break, configuring the modem would be hell after each upgrade.

The attitude that you must not break LibreOffice is not okey but breaking the file-system okay 'because it's a driver!' is just untenable.

Making people's computer fail will turn users away. It's not just a Linux thing. When Windows breaks stuff, all hell break loose on the Internet. The problem with OSS, is that its maintainers have no direct, immediate monetary incentive to amend. The long-term loss of confidence is hard to measure, but it's real.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by vetinari on Monday January 28, 2019 @11:46AM (#19018897)

Using internal kernel APIs is a pretty long way to being userland. Internal APIs are guaranteed to be broken, and for in-tree modules, the breakage is fixed by those, who break it. External modules have to do fixes themselves, thus motivating them to become in-tree.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by imhoguy on Monday January 28, 2019 @12:52PM (#19019458)

"v5.0 removes the ability from non-GPL modules to use the FPU or SIMD instructions"

Any reason why?

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by anon1385 on Monday January 28, 2019 @01:13PM (#19019648)

Well you can read the thread on the mailing list but to put it bluntly - because they wanted to stop ZoL from working. They view non-GPL kernel modules as a violation of the GPL.

"My tolerance for ZFS is pretty non-existant" Greg Kroah-Hartman

"please switch to FreeBSD instead of advocating to violate the copyright and licensing rule on my and others work." Christoph Hellwig

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by cthalupa on Monday January 28, 2019 @02:27PM (#19020287)

For context, Hellwig is the guy that tried to sue vmware in Germany and had the case dismissed because the evidence submitted summed up to references of stuff on the internet and basically copy and pasted git output. It didn't even include details on which lines of code were allegedly used by vmware, or details on authorship in any of the code comparisons that were present.

Which is a shame, because it would have been nice to see if the shim usage pattern is actually a violation of the GPL - a lot of us would like a clear ruling there. I'm sympathetic to his viewpoint, but that whole ordeal was a bit of a "wtf?" because of how it was handled, and I can't imagine him being sympathetic to anything else in an even somewhat similar situation.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by monocasa on Monday January 28, 2019 @04:17PM (#19021174)

AFAIK, the VMware stuff is beyond shim usage. They straight up replace the kernel and run GPLed drivers inside their kernel.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by shawnz on Monday January 28, 2019 @01:49PM (#19019986)

> They view non-GPL kernel modules as a violation of the GPL.

But then why allow them?

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by bluGill on Monday January 28, 2019 @02:54PM (#19020495)

users demand it. If the kernel devs pushed too hard legally a lot of users would switch to BSD (probably freebsd, but there are other good candidates). Linux is slightly better for desktop users, but if you cannot use your graphics hardware for legal reasons BSD will still work and is the lesser evil.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by shawnz on Monday January 28, 2019 @03:36PM (#19020834)

So basically NVIDIA gets a monopoly on the ability to release non-GPL linux kernel modules so that Linux can have a better reputation among desktop users (which is only a small fraction of Linux use in the first place)?

I don't get it -- do they care more about what the users want, or about enforcing copyleft? If it's the latter, then they should be happy if those users who don't care about the GPL move to BSD. If it's the former then they should stop playing games and implement a fair policy for all non-GPL module authors.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by bluGill on Monday January 28, 2019 @03:49PM (#19020936)

they is several thousand people with different motivations and desires. To expect them all to have a common motive would be a mistake.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by shawnz on Monday January 28, 2019 @03:52PM (#19020971)

People not associated with the leadership of the project shouldn't be making decisions about what licensing models are acceptable or not in the first place.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by erinnh on Monday January 28, 2019 @01:19PM (#19019690)

Because the kernel dev decided that interfacing with the kernel through the API would change the kernel too much to not be in compliance with the GPL if your license isnt.

Its not non-GPL. Its non-GPl-compatible.

[ Parent | on HN ]

Re:The potential risk to ZFS created by the shift in its use... by Dylan16807 on Monday January 28, 2019 @02:06PM (#19020137)

Which is proooobably a lie. It's pretty hard to imagine how such a generic function as enabling and disabling the fpu could mean that you're combining the two works. But there's not much process to call someone on technically inappropriate use of _GPL. It's a mostly-political tool pretending to be a technical tool.

[ Parent | on HN ]