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

NFSv2 is _painfull_ slow as it uses UDP (which also means: manual error
checking and (at least) two context switches per packet). NFSv3 brings
many improvements here (uses TCP which moves error checking into TCP
layer and uses continuous streams instead of single packages).
> - Security is difficult.
Again... the NFS-is-insecure-mythos... seems it will never die. Starting
with NFSv3 SecureRPC, Kerberos4/5 or GSS-API may be used for
authentification, too.

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

That's NFSv2 - with all it's side-effects listed in Pavels podfuk-old
docs. Still trying to "hunt-down&kill" a better solution... =:-)

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

Which involves SunRPC and many context switches. I'd like to take a
shortcut... :-)

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

At least it would be a much shorter way than going thougth all instances
of server<-->SunRPC<-->UDP/TCP<-->IP<-->UDP/TCP<-->SunRPC<-->client 

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

That sounds the first&easier way to go. 
But for the "long run" there's no way in hacking my own kernel module...
;-(

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) Roland.Mainz_at_informatik.med.uni-giessen.de
  \__\/\/__/  gisburn_at_informatik.med.uni-giessen.de
  /O /==\ O\  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
 (;O/ \/ \O;) TEL +49 641 99-13193 FAX +49 641 99-41359