Hi all,

 This weekend, I have been experimenting a bit with Coda 4.1.2. The system
I used consisted of a server machine (486dx2 66MHz, 16MB RAM, 24MB swap),
which was connected through a serial cable (115200 bps), to a client machine
(Pentium 100MHz, 24MB RAM, 8MB swap).

Setting up the Venus was simple, simply editing /usr/coda/etc/vstab.

Some problems I encountered were:

1- When venus crashes, and I restart it a couple of times without unmounting
   /coda. I start to get kernel Oopses, and after unmounting cannot rmmod the
   coda.o module because the `module is in use'.

   BTW. When I'm not stress-testing, I ALWAYS do,
     vutil -shutdown
     umount /coda
     rmmod coda

   That way, every venus restart was as clean as possible.

2- Because of the slow connection Venus quickly switches to Logging state,
   this gives a beautiful SIG11 when untarring the coda-source.

   When venus runs out of Modify Log Entries (MLEs). An assertion fails at
   venus/vol_cml.c:611. Reinitializing venus with more MLEs is a possibility,
   but not an option. I don't know how many I would need in advance, and,
   although it's slow, I am connected to the server.

   Somewhat related question, WHY does venus log through 3 different channels?
   There is stderr, venus.cache/venus.log, and etc/console. It's pretty hard
   finding out what went wrong. i.e. I forgot about etc/console, where a
   beautiful `assertion failed' message was waiting for me.

3- I got a `cfsnc_enter: Duplicate cache entry; tell Peter.' message.

   Well, Peter, consider yourself notified :)



Vice setup cost me an whole afternoon. My mayor gripes are:

1- The configuration files are seemingly spread all over the system, many
   contain the same information. For instance /vice/.hostname and /.hostname.
   These are completely probably useless if one uses gethostname() or
   uname() or (in scripts) `hostname`.

2- Most of the numbers in the configuration seem completely arbitrary, but
   some do have a `special' meaning. I set up rvm with a 10MB data segment,
   but then a heap-size of 0x1000000 sent rdsinit into the woods. Using
   the more conservative 0x800000 worked. (heap is fitted into the data
   segment and I at first tried to fit 16MB into 10MB data :).
   And why is the VSGDB entry E0000100? any relation to ip-adresses or
   completely arbitrary?

3- Most of the script won't work without changes, especially the locations
   of the binaries seem to change from script to script. And when a
   `not-corrected' script is run, it mostly leaves the system in a (semi-)
   inconsistent state.
   
   ps. createvol is especially funny:
   Cannot execute /System.map.
   `IBM' not found.
   etc. 

   The blurbs comments are wrong! /* IBM .... */

A bug in Vice is:

1- I created a volume `coda.root', which got an id of 41000003. The command
   `volutil lookup <volume-name or id>' couldn't find the volume, not by name,
   nor by id. Only when I used `coda.root.0' works. The volume lookup fails
   in vice. (as seen from errormessages in srv/SrvLog)
 


Thus far it's been a fun weekend, and despite all the problems I'm still
impressed. Aside from the small bugs, many configuration issues should be 
resolved (made simpler). When setting up a Coda client-server system becomes
as simple as, for instance, a no frills NFS service, the general public will
definitely embrace Coda as their networking filesystem of choice.


Jan Harkes <jaharkes_at_cwi.nl>