(Illustration by Gaich Muramatsu)
On Tue, Oct 09, 2001 at 07:05:59PM +0900, Stephen J. Turnbull wrote: > >>>>> "Jan" == Jan Harkes <jaharkes_at_cs.cmu.edu> writes: > > Jan> Actually this is a FAQ, the untar very quickly creates many > Jan> files. When creating the many directories the server slows > Jan> down and as a result clients assume this is due to network > Jan> congestion and back off quite agressively by switching to > Jan> write-disconnected operation. > > I'm having a similar problem with CVS updates. An update in a big > tree (XEmacs) often terminates with a Coda timeout (unfortuantely I > don't have a log around because I'm having worse problems with coda, > so the cron job hasn't found anything to update in days---separate > msg). AFAIK cvs updates do not create many files (assuming few > changed files, which is the case here; AFAIK the only thing they > always create is CVS/Entries.backup in each directory), but they do do > a lot of stats. > > Could this be the same problem? Hmm, If there is an timeout the problem can be the same. But I have an new one wich looks something different. I have created an tree with different volumes on different servers but all are non replicated. Then I make a cvsup (under FreeBSD) for checkout the sources of FreeBSD. Cvsup creates a lot of files and directorys. But after a small time venus died without any message and /coda is not accessible. Then I shutdown venus with vutil shutdown. The shutdown then gives me an RecovTerminate: dirty shutdown (1 uncommitted transactions). Next I try to restart venus with venus &. That fails with: 12:47:17 /usr/coda/LOG size is 549376 bytes log_recover failed. do_rvm_options failed 12:47:17 Recov_InitRVM: RVM_INIT failed (RVM_EIO) So I do an venus -init & wich works and then try again my cvsup command. The point, venus stopped working is always different and I can't find any hint in the venus.log. How do I debug such thing? Many thanks Matthias -- Matthias Teege -- matthias@mteege.de -- http://emugs.de make world not war PGP-Key auf AnfrageReceived on 2001-10-10 09:34:24