I've been looking more carefully at Coda recently, as my departmental
net admins in their infinite wisdom have decide to subscribe to
Microsoft updates (they multicast >500MB disk images, I'm told :( )
which basically shut down my gateway at random intervals for 5-20
minutes at a stretch.  They refuse blame, pointing out that if the
University had finished upgrading the campus net to 100MB in July as
promised, I'd be on a different subnet.  The U. has stopped making
promises (urk).

So a caching filesystem seem like a GoodThang[tm].

My current setup is mail host on the other side of the gateway,
procmail splits the spool into folder-specific spoolfiles, and use
XEmacs+VM on the mail host with X display on the local workstation.

1. My initial thought was to move the split spoolfiles to somewhere
under /coda, and use XEmacs+VM locally.  A little reflection convinced
me I'd be shooting myself in the foot, as in disconnected periods both
VM and procmail would be updating the spoolfiles, guaranteeing
conflicts every time I actually needed Coda's cache.  (Worse, neither
copy is correct, the mail host copy contains the new data, but the
codasrv is on this side of the beseiged gateway.)  True?

2. OK, so instead of spoolfiles, I use a maildir (file-per-message).
This wins.  True?  (I have to change mailreaders, VM doesn't grok
maildirs very happily.  I'll live.)

3. For a while I was getting server crashes with rvmalloc errors.
(Does that really have to crash?)  Then I moved some junk out of the
filesystem where the server's RVM file was (it was down to a couple MB
free), and haven't seen them since.  I shouldn't see any more, right?

All of the following relate to Coda 5.3.15, built locally from CVS
updated on Sept 12, using debian/rules and my local mods to make
--srcdir work with debian/rules.

4. Now I'm stress testing the system.  I'm running both the server and
a client on a 450MHz PII 256MB RAM box, as well as X and XEmacs, which
is a pretty heavy load, basically always in swap.  I've seen no
problem with interactive response in the Coda FS.  I'm also CVS
updating four large XEmacs modules, the Coda sources, and Ghostscript
sources by cron at inactive periods.  Each job runs to completion
before the next starts.  I'm not sure how much Coda activity this
involves, but I am seeing codasrv crashes every few days, always in
one of the cron jobs, leaving behind hundreds of CMLs in the client.

The SrvErr says

bash-2.05$ cat /vice/srv/SrvErr.prev 
Assertion failed: 0, file "/coda/Projects/Coda/coda/coda-src/vice/srv.cc", line 324
EXITING! Bye!

SrvLog is attached at the end.

5. When the server comes back up, the client seems to need to be poked
with a "cfs cs" or it won't reconnect.  I'm not very patient, though,
maybe there's a >60 sec or so timeout involved?

6. The client doesn't seem to like "cfs fr" very much either.  It
reintegrates properly by itself most of the time if it's logged in
already.  But if not, trying "cfs fr" gives some error VIOCSYNC = -1,
and doesn't reintegrate.  In those cases things seem to get kinda
wedged.  Since almost all data currently on the Coda FS is CVS stuff
from remote repositories, I don't hesitate to stop venus and reinit
its RVM, but obviously once I've got personal data there that won't
do.  (The one thing I know I've lost is the redirected output from the
last time I saw that error, so I'm reconstructing from memory :-P )

The promised SrvLog:




-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."