apr repository!

[Ben Collins-Sussman <su...@newton.collab.net>]

Hey, I can update my apr/ directory really fast now; it used to take
forever.  Is this because Brian has somehow fixed a caching problem on
www.apache.org?  Is apr's repository living on a new box, now that
it's an independent ASF project?

Just curious.

Re: apr repository!

[Brian Behlendorf <br...@collab.net>]

On 13 Nov 2000, Ben Collins-Sussman wrote:
> Brian Behlendorf <br...@collab.net> writes:
> 
> > I put /tmp on an MFS, since cvs pserver uses /tmp pretty
> > heavily.
> 
> MFS == Memory File System?  Is this some kind of RAM disk?

yes.  since /tmp is definitely not required to survive a reboot, and we're
OK on memory usage (aside from CVS clients like the one I posted about =)
it seems safe.  Looks like CVS makes an entire copy of what it wants to
send to a client to a dir in /tmp before sending it out; makes a bare
minimum of sense if you have reads locking writes to the repository, so
it's not locked while someone does a big long read-only update.

	Brian

Re: apr repository!

[Ben Collins-Sussman <su...@newton.collab.net>]

Brian Behlendorf <br...@collab.net> writes:

> I put /tmp on an MFS, since cvs pserver uses /tmp pretty
> heavily.

MFS == Memory File System?  Is this some kind of RAM disk?

Re: apr repository!

[Brian Behlendorf <br...@collab.net>]

On 13 Nov 2000, Ben Collins-Sussman wrote:
> Hey, I can update my apr/ directory really fast now; it used to take
> forever.  Is this because Brian has somehow fixed a caching problem on
> www.apache.org?  

I put /tmp on an MFS, since cvs pserver uses /tmp pretty
heavily.  There was one other change to how directory lookups are
cached that may have also helped.  Glad to see it made an actual
difference!

	Brian