(Illustration by Gaich Muramatsu)
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."