Coda File System

Re: venus randomly dies

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Fri, 2 May 2003 11:33:46 -0400
On Fri, May 02, 2003 at 12:26:57AM -0700, Steve Simitzis wrote:
> On 05/01/03, Jan Harkes <jaharkes_at_cs.cmu.edu> wrote: 
> > I'm not sure how easy it is to change this. There definitely isn't a
> > command line or venus.conf option, so it would require a recompile.
> 
> so then, does it help me to run maxclients at 100, or is that excessive?
> i'm unsure how to best tune that number. is there a tool for observing
> what venus is doing with its clients?

Well, maybe we should really tie the number of rpc2 connected per user
to a percentage of the number of worker threads. Something like 50%+1
(to make sure that it works even with a single worker thread).

> > The thing that is interesting in your log is that all objects have a
> > 'writer'. What kind of updatedb or slocate is running on your system?
> > It might be opening all the files O_RDWR, which triggers venus to write
> > back all the files after fetching.
> 
> that's a good question. i'm running slocate 2.6, that came standard
> with the redhat install this machine is based on. i added /coda to

I just looked at the slocate 2.7 source and it only opens things
O_RDONLY. Maybe I'm misinterpreting the writers bit, perhaps anyone who
is fetching a files into the cache is a 'writer' because it is mutating
cache state... Have to check that out some time.

> updatedb.conf, so perhaps that will help matters. it seems that
> updatedb starts in cron at 4:02am, which matches the 4:03am where the
> log spew begins.

I saw 04:0 something and immediately thought 'updatedb run'. It is a
pretty decent exercise for Coda's cache replacement code. And clearly
there are several problems still hiding there somewhere.

Jan
Received on 2003-05-02 11:36:49