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 Received on 2000-10-17 17:23:03