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
> http://atrey.karlin.mff.cuni.cz/~pavel/podfuk/podfuk.html claim that NFS
> doesn't fit the needs ?

He has some explaination in his podfuk-old page.

http://atrey.karlin.mff.cuni.cz/~pavel/podfuk/podfuk-old.html

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

ftp://ftp.debian.org/debian/dists/unstable/main/source/net/nfs-user-server_2.2beta47.orig.tar.gz

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

Jan