[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idea for reducing disk IO on tagging operations

From: Todd Denniston
Subject: Re: Idea for reducing disk IO on tagging operations
Date: Mon, 21 Mar 2005 09:56:23 -0500

"Mark D. Baushke" wrote:
> Dr. David Alan Gilbert <address@hidden> writes:
> > > FWIW: (In my personal experience) using a SAN
> > > solution for your repository storage allows you
> > > much better throughput for all write operations in
> > > the general case as the SAN can guarentee the
> > > writes are okay before the disk actually does it.
> >
> > But when you throw a GB of writes at them in a short time from a tag
> > accross our whole repository they aren't going to be happy - they are
> > going to want to get rid of that backlog of write data ASAP.
> I believe you will find that the performance knee for a commercial SAN
> that is well provisioned happens when you hit a 2GB of sustained writes.
> You are more likely to run into problems with bandwidth to the
> fiberchannel mesh first.
> For us, I seem to recall that the actual bottleneck is the creation of
> the /tmp/cvs-server$$ trees for a 'cvs tag' operation. So, you results
> will also depend on how shallow or deep your module hierarchy runs.

This reminds me of conversations held earlier in the list.  I think several
of them ended with something to the effect of 'putting the /tmp/ or LockDir
which cvs uses on a RAM disk should make the whole thing _much_ faster'.
a note with some comparison of speed using memory backed filesystem:

Greg once indicated that if you have a bunch of tags which are meaningful
for only a short time it MIGHT save some processing to clean them up some,
but I don't think it really affects the situation posed by the Dr.
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter

reply via email to

[Prev in Thread] Current Thread [Next in Thread]