Coda File System

Re: design, go beyond AFS?

From: Jan Harkes <>
Date: Tue, 20 Aug 2002 22:51:27 -0400
On Tue, Aug 20, 2002 at 10:31:43AM +0200, Ivan Popov wrote:
> Glad it looked reasonable for you too.

It is quite reasonable, even implementation wise. I fixed the client to
not care about volumename lengths, modified GetPath to optionally do a
realm-relative pathname lookup and added a call to GetPath whenever we
get an empty volume name. Ergo, it looks like it is 'working' in my
development tree.

Ofcourse the servers don't know how to handle >32 character volume
names. At least they don't seem to crash when my client asks for
a volume named /usr/jaharkes/test/mountpoint :) Now we could either
splice a pathname -> volname mapping before the VRDB lookup, or break
the client-server protocol (and a lot of server code) to allow for
volumenames with a possible length of MAXPATHLEN. As the new client
still has some problems (i.e. repair doesn't work) that will take a
bit longer (no, it won't be done tomorrow!).

So right now we are at a point that we can try your semantics on a
limited scale (i.e. up to 32 characters), but it proves a point. And
it is enough for most of our user volumes, although the 'production'
clients would probably not be happy with new mountpoints.

The new stuff is all on the experimental branch 'coda_20020715_realms'
in CVS. If you are inclined to play with it don't forget to patch your
kernel module, it needs a different definition of ViceFid similar to the
following change (I really should bump the kernel version number).

  struct ViceFid {
+     long realmid;
      long volumeid;
      long vnode;
      long unique;

Also, don't be surprised when ls /coda shows nothing, just do ls
/coda/ and hopefully everything will become
clear. Most things are working, hoard, cfs. And it works fine with
existing servers. There are probably some small problems lurking and
repair is still in a state of disrepair, but that's about it.

Received on 2002-08-20 22:53:31