Coda File System

Re: Re: FUSE, again

From: <u-x417_at_aetey.se>
Date: Thu, 22 Nov 2018 15:12:59 +0100
On Thu, Nov 22, 2018 at 08:37:10AM +1030, Brett Lymn wrote:
> On Wed, Nov 21, 2018 at 05:55:40PM +0100, u-x417_at_aetey.se wrote:
> > 
> > (Don't most file systems need their specific kernel modules? Good or not
> > but isn't this the status quo?)
> 
> A lot of them are tradition... I am pretty sure that NFS on Linux is all
> userland.

I meant actually "file systems" which includes the local ones like ufs
and ext* and lots of others, most using dedicated kernel modules. As
for FUSE counterparts, ZFS has dropped its FUSE implementation, which
regrettably neither ever had all the features of the "native" one.

> > 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.
> 
> No, the kernel module does a lot more than that, at least on NetBSD,
> the kernel module hooks into the UFS code to perform directory
> processing and a few other things.  In fact this hooking resulted in a
> very long standing bug in the NetBSD venus process where coda and ufs
> disagreed on the size of a directory block size - this caused directory
> entries to "disappear".

You mention file operations, but I meant pioctl operations and nothing
else. Of course the kernel is deeply involved in every Posix-like syscall,
but very differently (and almost entirely unnecessarily) in the pioctl ones.

> > 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?
> 
> From wikipedia - OpenBSD, OpenSolaris, Minix 3, Android, MacOS.

In a slightly different order:

Minix 3 is (regrettably) in a very underpowered state. If I would
consider porting Coda to it, it will be most probably much easier to do a
Coda-specific module than ensure that FUSE is good enough for Coda needs
(I can not remember hearing about anyone using FUSE on Minix in practice)

Android is Linux. Coda is actually usable there, modulo the shortcomings
of the platform itself.

MacOS?
Apple consequently showed that Coda is not welcome. They killed both the
kernel module (you could no longer build it) and then the fully userspace
implementation (Ulocoda) by limiting the access to interception on libc.

I can't say anything about the state of FUSE on OpenBSD or OpenSolaris
but in the context of Greg's letter, these OSes are hardly mainstream enough
to make Coda mainstream.

> If FUSE support was built into venus then, potentially, coda would be
> able to run on these operating systems too... I don't know how useful it
> would be but Coda on a phone would be pretty cool ;)

It was of course useful (all data - at hand, taken pictures - ready to view
elsewhere), yes I did use Coda on an Android phone. (It ceased to be used -
the phone and that OS.)

Regards,
Rune
Received on 2018-11-22 09:24:02