News for hackers. Stuff that matters.

A comment on The potential risk to ZFS created by the shift in its userbase. Parent comment

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 ]