u-x417_at_aetey.se writes:

> Hello Greg,
>
> On Wed, Nov 21, 2018 at 09:32:54AM -0500, Greg Troxel wrote:
>> Currently, one has to have a kernel module just for coda.  This used to
>> be the only way it could have been done, but is now boutique.  If every
>> filesystem needed its own special module, the overall situation would be
>
> (Don't most file systems need their specific kernel modules? Good or not
> but isn't this the status quo?)

Of all the ones I hear about people running, Coda is the only one.

>> Now, almost all filesystems that have user-space implementations --
>> perhaps everything but coda -- use FUSE
>
> As far as I can see few of file systems have requirements similar to
> Coda. One filesystem with a similar design and a user-space cache manager
> (AFS) happens to use a dedicated and complex kernel module.

I had forgotten about AFS.  Still, to me the poster child for FUSE being
workable is gluster.  There is no AFS module in the NetBSD, and the
openafs pkgsrc package doesn't seem to have a NetBSD kernel module.
(There is NFS, but that's an in-kernel implementation.)

>> and a filesystem I can't run everywhere
>> effectively has zero performance because it doesn't meet basic
>> requirements and thus can't be used.  However, supporting FUSE, and not
>> having the kernel module work are separate issues, and it's entirely
>> possible to have a FUSE method that is portable and a kernel module that
>> is perhaps somewhat faster.
>
> I am afraid that FUSE is not as portable as it could be desired,
> especially if the high-level interface would be insufficient.

Perhaps, but it's better than a boutique module.

I am pretty sure the high-level interface would be ok; I'm not sure why
gluster can't use it.

>> The second issue is about pioctl and the extra signaling path, but I see
>> no reason that can't work with magic filenames and ioctl.
>
> This is imho what really should be fixed, FUSE or not.
>
> With all due and enormous respect to the early developers, this
> communication channel is flaky, both in design (ioctl is a really bad
> tool, given that we handle a pure IPC/RPC between user processes and
> venus; the only role of the kernel is to help process authentication,
> not having to be aware of the data to be passed) and as a result also
> flaky in the implementation.

I don't see why this would be flaky; a FUSE ioctl would simply be passed
to the userspace daemon (venus), with the data being opaque (perhaps
with an interpreted length).  This is basically RPC, with data copied
out/in with permissions validation.

> All of the kernels where we have Coda today provide means for an
> authenticated local socket connection, unfortunately not in the same
> way, but this could be abstracted in user space, not in the kernel as
> it is now. This can fully and much more flexibly replace pioctl.
>
> There are also other, possibly more portable possibilities, like using the
> present and full-featured rpc2 framework over a local network connection
> (as long as we can safely establish a relation between dedicated rpc2
> secrets and local uids).

Sure, but it seems FUSE ioctl (or read/write on magic filenames) gets
this for free.

That said, I don't have a strong opinion, as long as there's nothing
unportable (less portable than FUSE) and there is strong authentication
from the unix userid via the operating system without having to
configure it (bootstrapping from the kernel's enforcement of uid in
things like fuse and kernels modules).

>> Without FUSE, I think coda will continue to exist in the margins and has
>> no real hope of mainstream use.  Certainly I am unlikely to start using
>> it again in this state.   So I ask that you consider FUSE support as an
>> important priority.
>
> Frankly I doubt whether FUSE would make a big difference. We have already
> kernel support for Coda in Linux, NetBSD, FreeBSD. Which platform would
> you look forward to, which has a usable FUSE but a different kernel than
> one of the above?

Mac: https://osxfuse.github.io/
OpenBSD: https://undeadly.org/cgi?action=article&sid=20131108082749

But any system that wants to play in experimental filesystems has to
make fuse work, and then they can do a lot.  That's far more efficient
than having to do somethings that's more or less like FUSE but isn't per
filesystem.