Wow!  Coda development is *moving*!  I'm majorly impressed.

> It is possible to dramatically improve the portability -- at least
> as a first shot at it -- by modifying a user level NFS server to
> provide a mountable file system on one end, and speak to the Coda
> cache manager running on the same machine on the other.  ... Coda
> could then be ported to all Unix systems without writing kernel
> code.

Exactly my thought when I designed my Pgfs version-control filesystem
and its successor, WVfs.  WVfs is not yet functional, but the NFS
demux portion that breaks out NFS operations into function calls and
prettyprints them is working and stable, if ugly.  This code is a
proof of concept and takes lots of liberties with types, but it's
reliable.  Is it significantly smaller and simpler than other
user-level NFS servers I've seen (Linux, cfs, tcfs).  WVfs is GPL.
Other licenses that adhere to the spirit of the GPL are possible, or
you can just play with it for educational purposes.  See also my Pgfs
article in the October Linux Journal.  WVfs code is available at
ftp://ftp.pn.com/pub/bb/wvfs.  To demo it as a filesystem follow the
instructions in INSTALL.  To use it as an NFS demux replace the
nfs_*.c files with your code.  I'll be happy to answer any questions.

> From here our next target is to get mount to work.

The problem with using mount(1) is you have to get rpc.mountd/
exportfs function working first.  I don't know how to export something
when it doesn't first appear as a pathname on the local system.  If
you do reverse-engineer all these undocumented system interfaces I'd
love to have the code.  I'm going to reread Peter's discussion of
rpc.mountd carefully.  You may bypass getting mount/umount/df/
rpc.mountd working by passing a known NFS file handle and an open
socket to a known port to the mount system call.  This is what the
mountwvfs program does in WVfs.  (It's also what you need to use an
NFS server without exportfs permission, if you've sniffed an NFS file
handle for a directory off the wire.  I'll be glad when I can use
Coda.)  To undo the mount, umount(8) complains, but works.  Under
Linux, when my user-level NFS server stops answering, the processes
dependent on the files mounted from it freeze.  However, they reliably
exit on a kill -9.  I've never seen Linux get flaky, even from hours
of taking NFS servers out from under it.  Hint: Test your NFS server's
operation by reading or writing to its filespace with cat or dd, never
with shell redirection.  Reason: You can't identify the right shell to
kill in a ps listing.  Oops!  Wrong shell.  Oops! ...

> (that's 12 bytes out of 32 available ones)

Note: 32 bytes means NFS version 2, semi-sorta-documented in RFC1094.
I don't think Linux implements version 3, but I may be out of date.

While you have lots of printf's in your NFS server, you'll get better
results if you lengthen the NFS retransmit interval "acregmin" in the
mount options to something like 60.  Otherwise you will get
retransmits with each packet and you'll be repeating Coda queries.


Another member of the League for Programming Freedom (LPF) www.lpf.org
-------------------------------------------------------------------------------
Brian Bartholomew - bb_at_wv.com - www.wv.com - Working Version, Cambridge, MA