uberbaum and fileattr

Jason Molenda jason-swarelist@molenda.com
Sun Nov 11 09:02:00 GMT 2001


On Thu, Dec 20, 2001 at 09:48:51AM -0800, Angela Marie Thomas wrote:

> negligible.  A lot of things have changed between the time it was first
> written and today.  Our internal CVS server is running very noticeably
> faster with significantly more RAM and a ramdisk for /tmp.

It's all true -- y'all are using a cvs server that is distinctly
faster than the old one, and you probably have fewer internal
engineers pounding on the cvs server, and many of those internal
engineers are probably distributing some of their load on to
sourceware.  

> > You can declare this worst case to be too unlikely to skip the obvious
> > ramdisk optimization, but it's good to be aware of it.
> 
> I don't see how this is any different from cvs-tmp running out of disk
> space.  What am I missing?

The largest checkout is 210MB (I checked).  So you'd want to make
a ramdisk for cvs-tmp of around 250MB (I thought it would be larger).
That's not such a problem if you can afford to lock up that much
memory.  sourceware today has 768MB, so even in its current
configuration, it'd be possible to set this up.  Presumably any
new sourceware system would have 1-1.5GB of memory.

One other optimization that cvs 1.11 can do (which 1.10 can't,
without some back-patching) is put its lock files in a separate
directory, preferably a ramdisk (cf CVSROOT/config).  This requires
little disk space and eliminates the write operations the cvs server
needs to do while serving a cvs update request.  It's a small (I'd
guess single-digit percentage) performance boost, but an easy one
to do.

Jason



More information about the Overseers mailing list