Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA00361; Wed, 6 Dec 95 21:34:51 EST
Received: from FOREVER.MIT.EDU by MIT.EDU with SMTP
	id AA08994; Wed, 6 Dec 95 21:33:44 EST
Received: by forever.MIT.EDU (8.6.12/4.7) id VAA02170; Wed, 6 Dec 1995 21:34:53 -0500
Message-Id: <199512070234.VAA02170@forever.MIT.EDU>
To: miki@MIT.EDU
Cc: dcns@MIT.EDU
Subject: Re: New Solaris disk partitions 
In-Reply-To: Your message of "Wed, 06 Dec 1995 14:42:34 EST."
             <9512061942.AA27933@tamar.MIT.EDU> 
Date: Wed, 06 Dec 1995 21:34:52 EST
From: Matt Braun <mhbraun@MIT.EDU>


I've been thinking about this and I have a couple objections. The first is
that Derek has a good point, most of the Sparc Classics have 400 M disks.
The current partitioning is approximately:

	/		30M
	/usr		60M 	
	/var		200M 
	/var/vice/cache	46M
	swap 		48M 

If you made swap and cache bigger you will only have 100 M of /var which is a
little small (I think atleast 150 M would be better so there is room for all
of the system logs and temp space for users.  Of course by nature, the 400 M
disks need a different partition table on the install server, so having a
different partitioning is not a big deal.  In that case I would suggest that
the swap be uniform across different Sparc disks and the cache be smaller on
400 M disks than 500 M disks.

My other objection is the AFS cache.  The idea of a 100 M AFS cache gives me
a bad feeling.  A back of the envelope style calculation for usage would look
something like this

	5M for stuff in users homedir
	15M for system binaries (keep in mind a fair amount of common stuff is
		local) 
	20M of Applications (Frame, xzewd, etc) 

This gives about 40 M of cache a normal user is likely to use.  Since much of
the system binaries and some of the Applications would stick around for other
users additional cache would result in user files being stored on local disk
much longer than they already are.  The persistence of user files on public
workstations is a real concern and the argument has been that they do not
stick around for very long because of cache turn over.  If we had 100 M of AFS
cache personal files would stick around for long periods of time (weeks ?).

Based on the 40 M off the cuff calculation I would therefore recommend an AFS
cache size of 50-80 M (preferably 60ish).

I understand that developers in particular tend to use a lot of AFS cache when
doing builds into AFS, but I don't think that they represent the normal
practices of our users and the default configuration should be tuned to the
bulk of our users rather than the developers who are free to customize their
machines.  One compromise I could see is have the AFS cache partition be 100
M and the default AFS cache be 60 (with the appropriate changes to AFSADJUST
in rc.athena to make that stay that way).  If we did that then it would be
fairly easy for developers and private workstation owners to up their cache
size and not compromise more user data than we must.

			
				Matt

PS Do we want to take this discussion somewhere other than dcns? maybe
rel-eng or athena-ws ? 
