[381] in Release_7.7_team
Re: New Solaris disk partitions
daemon@ATHENA.MIT.EDU (Bill Cattey)
Thu Dec 7 22:21:06 1995
Date: Thu, 7 Dec 1995 15:00:09 -0500 (EST)
From: Bill Cattey <wdc@MIT.EDU>
To: rel-eng@MIT.EDU
Cc: release-team@MIT.EDU, miki@MIT.EDU, nschmidt@MIT.EDU
I've reviewed the TRB minutes BOTH on disk partitioning, and on the
exposure of files in the AFS cache.
I have raised questions in the Athena release team meeting about the
partitioning issue -- where it comes from, where it it going, etc.
I have talked with miki about what to do.
Here is a gathering of the information as I have it:
1. The exposure of user files to snooping in the AFS cache has been
known about since 1992. The final decision of the old Athena Technical
Review Board was that users should be educated to use "fs flush
<sensitive filename>". As far as I know as soon as we felt we had the
solution, we never followed through with implementing it, and everybody
forgot about it until Matt brought up the issue as the other objection
he had to enlarging the cache.
2. Increasing swap size is a motherhood and apple pie issue.
Consultants and various users encounter situations where the solaris
swap size being too small has bit people. This partition SHOULD just
increase.
3. Due to ambiguity in Miki's original message, it wasn't clear that she
intended not to change the parameters of the 400 meg systems.
4. Discussion elsewhere led to the assertion that shrinking /var, even
on 400 meg systems to increase swap would not be a bad thing.
5. Transaction #68 of the trb minutes in discuss shows that the most
important issue in configuring the workstation is PERFORMANCE (as
perceived by the user running programs on it.) The criteria evaluated
were:
1) performance
2) ability to vary swap and cache
3) providing usable disk space for the end user
4) our ability to change the required sizes of system partitions.
Comparing the relative importances the scores were:
21 for performance
2.1 for ability to vary
6.1 providing usable disk space
2.2 ability to change the required sizes.
6. Since that analysis was made two things have changed:
Solaris, starting with 2.4, will swap out of the disk image instead of swap.
We've become more committed to making life easier for private machine owners.
The consequences of this change are:
We don't know what the actual performance is of the partitions as they
are placed around the disk any more.
We don't know whether it's more important to private workstation owners
to have big /var or to have easy swap changing.
----
Conclusions, and what action should we take:
1. Miki and others believe that performance will improve by enlarging
the AFS cache. The single site with the very large program that can't
run until AFS cache size is increase will probably represent a more
common situation.
2. Restricting performance as a way to finesse a security issue, rather
than dealing with the security issue is probably a mistake. I suggest,
rather than restricting AFS cache size in the hope of reducing the
number of user files that stay there, the old solution of educating
users about "fs flush" should be implemented.
3. The 500 meg disk partitions should change.
4. They should DEFINITELY increase swap to 100 meg.
5. They should Probably increase AFS cache to 100 meg.
6. Owners of private workstations should be warned that the size of /var
is shrinking,
and that they should plan to move their files if they have a totally
full /var partition.
7. Partitions on 1 gigabyte drives should allow an even larger swap
space, and probably a larger AFS cache.
----
Bottom Line:
Miki should go ahead and change the 500 meg partition to be 100 meg
swap, and 100 meg AFS cache.
-wdc
