Subject: Re: OT: recommendation for vm tuning for anoncvs mirror?
To: None <>
From: Jeff Rizzo <>
List: netbsd-users
Date: 02/26/2005 17:07:02
Thor Lancelot Simon wrote:

>On Sat, Feb 26, 2005 at 04:04:09PM -0800, Jeff Rizzo wrote:
>>Is the purpose of this for LockDir?  Not knowing a tremendous amount 
>>about CVS's internals myself, I wonder if some of the read-only 
>>repository patches available in later (than the 1.11.17 that comes 
>>w/NetBSD) CVS might help with this?  I wasn't originally planning on 
>>having separate spindles, but clearly I need to rethink this... I 
>>suppose I can simply not raid the disks, as all the data is mirrored 
>>from other sources anyway - I'll live with a dead disk taking the system 
>Read-only repositories don't use locks.  I don't know what changes
>you're referring to that aren't in the CVS in the NetBSD tree: I can
>assure you that has not run with locks, ever.

I'm talking about the CVSREADONLYFS env variable that (for example) 
OpenBSD's cvs seems to support, and that I think I saw mention of in the 
cvs 1.12.X distribution, but does not appear to be in NetBSD's cvs 
1.11.17.  It's quite possible (even likely) that I'm just missing 
something, but I can't get things to work unless I set LockDir to a 
writeable directory in CVSROOT/config.

>CVS uses /tmp for generating old (or branch) revisions of files, for
>generating diffs, etc.  It creates mirror directory structures of as
>much of the repository as it's been asked to check out, in /tmp, for
>every checkout (or diff, etc.).  This means creating tens of thousands
>of directories and files per copy, which is the reason for all of the
>effort to optimize the system to run efficiently with huge numbers of
>small directories.

Right.  Got it.  Thanks for the explanation.

>I suggest that you mirror / (and /usr, and /var, etc. if those are
>separate filesystems) and then use one partition on each of the two
>mirror disks for /anon-root and /anon-root/tmp respectively.  If you
>lose either disk, you can just drop a new disk in and trivially
>recreate either the anon-root you lost or let the boot process
>recreate an empty /anon-root/tmp for you. :-)

Doh!  The perfect solution!  :)  Now, assuming I can get the colo staff 
to swap my drives around so it will come back up after I inadvertantly 
wiped out my bootblocks... :)

Thanks again,