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