distributed filesystems

[Greg Troxel]

  [question about how to proceed]

I'm answering on-list because I suspect this may be of broader interest.

There is the kernel portion, and the userland code.  You should build
userland coda from coda's cvs (see attached scripts for NetBSD).  This
is lwp, rpc2, and rvm, and then coda itself (to get venus, the userland
client-side cache manager).  You'll want to join the coda mailing list
and look at the web site and wiki.

You just need a machine to run the client on.  The server doesn't need
kernel support and will be easier to re-port if necessary, but it's
harder to set up from a coda point of view.  There is a test server at
CMU you can use your client with.   In debugging the kernel code you are
going to have crashes, so it's best if you can have a separate box
(doesn't need to be fast) and even better if you can run kgdb.

The NetBSD version is also old, with some recent updates.  I think that
NetBSD and FreeBSD have diverged in terms of vnode protocol, especially
in foo_lookup, which is one of the harder routines.

There is also the "realms support" issue.  Coda uses a new venus/kernel
protocol (version 3) that supports muliple coda realms (administrative
domains).  FreeBSD should be updated to that if it isn't already; the
version 2 pre-realms version is now crufty and all coda people are using
realms-capable venii.

Big issues that I think you'll run into when porting the NetBSD version
to FreeBSD are:

  vnode locking rules are different.  NetBSD's rules have been
  regularized, with lookup taking a locked dvp and returning a locked
  vpp, leaving dvp locked, and fairly consistent vput for leaf
  operations.

  NetBSD has UVM, and so the interface to getpages/putpages
  is probably different.  Coda passes a file by dev/ino into the kernel
  and then vnode ops on the coda vnode get forwarded to the (ffs)
  container file.  This is tricky for handling page faults for executing
  a program, as the vnode isn't open.


I am on the verge of doing a KNF reformat of the NetBSD code; it's quite
clear that there's no upstream to merge from.  I'm not aware of anyone
in OpenBSD or Dragonfly hacking on coda either.  So if you want to start
from the NetSBD version I should probably do that.  I suspect it would
be ok to have things ifdef'd for FreeBSD so we could have one source
file - if you want to try that path I can inquire within NetBSD about
how that's handled.  My guess is that aside from locking rule
differences and getpages/putpages that the code will be very similar.
Plus, we've gotten rid of some vnodeops, but I suspect they are
unimplemented in coda anyway.

I don't mean to putting down FreeBSD to be talking more about NetBSD -
that's what I've been using lately and working on, and I'm therefore not
clear on the current details for FreeBSD, having last run 4.x.  I think
there's enough common heritage still that my experience can be helpful,
and I'd be thrilled if the fixed-up NetBSD bits can be snarfed into
FreeBSD - a lot of code goes back and forth and that's a good thing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: coda-build.tgz
Type: application/octet-stream
Size: 777 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070423/489945f4/coda-build.obj