Coda File System

Re: CODA kernel module limitations...

From: Jan Harkes <>
Date: Tue, 17 Oct 2000 17:09:20 -0400
On Tue, Oct 17, 2000 at 10:11:09PM +0200, Roland Mainz wrote:
> > For direct operations, hack podfuk into a userspace nfs daemon.
> Does this really work in all cases ? Why does
> claim that NFS
> doesn't fit the needs ?

He has some explaination in his podfuk-old page.

- NFS is a stateless protocol, and has consistency problems.
- Using NFS is very slow, probably because of the context switches.
- Security is difficult.

> And: AFAIK noone outside Sun has written a working NFSv3 server
> implementation yet (there are some NFSv2 server implementations out -
> but none of them look as they can be used to hook my work on...), all
> other vendors licensed Sun's code... ;-(

Pavel used the rpc.nfsd userspace NFSv2 daemon code. You can get the
source from f.i. the debian distribution.

> I'm looking for something like this:
>             glue
> kernel_vfs<------->userspace_vfs(midnight commander vfs/gnome vfs/etc.)

kernel_vfs<->nfs_kernel_client<->userspace nfs daemon<->userspace vfs

> Anyone seen something like this (e.g. the "glue") ?
> Forget performance problems for a few secs... I'm looking for a
> safe&portable way to hook-up new filesystems into a system. Writing
> kernel modules is not the right way - one mistake and the whole OS get'S
> killed. Bad.
> Ideas ?

Alternatively add additional upcalls to the Coda kernel module, but it
is likely to end up being the same thing, with the same problems as
using NFS for the kernel->userspace communication.

Or settle for the far simpler `lease' solution. For that we only need
one additional upcall, an additional return value for CODA_OPEN, and
some wrapper code in the kernel around read/write/mmap to ask the
cachemanager for another lease when file->fpos is beyond the existing

Received on 2000-10-17 17:23:03