SCSI and 386/ix

[Piercarlo Grandi]

In article <21600005 at adaptex> neese at adaptex.UUCP writes:

   Splitting up the filesystem is always a matter of the application.  If your
   system doesn't ever swap, then there is no gain to putting the swap on a
   second drive,

Well, in most timesharing applications your system _should_ swap.
A very rough rule of thumb is that if a resource is less than 30%
used it is wasted (and if over 60% used it is insufficient, because
queues will form on a resource that is more than 60% committed on average).

Given that the majority of processes in a timesharing system is
inactive, and possibly for fiarly long times, swapping/paging is
healthy. If it does not occur, than you have too much memory for
your application mix. If you don't want it to occur because it is
too slow, this means that the swap bandwidth is undersized.

Tuning is the science/art where your major resources, CPU,
memory, IO bandwidth are all used more than 30%, and less than
60%. Well, actually you may overcommit a resource, if it is so
expensive that latency can be tolerated (the forming of queues).

   but if it does swap, then this is absolutely true.  I always
   like to put tmp on the second device, as that directory is constantly being
   used in my system.  I put spool on its own partition on my root device to
   try to keep that dir from fragging my usr partition.  I have my news/notes
   partition on the second drive and swap.

The logic between having tmp on a disc different from your user
homes is that virtually every compilation, editing, etc...
creates a copy of the file in /tmp, that is eventually copied
back to the user home. The same rationale applies to having the
swapping on a different disc from where the executables are; you
want to be able to be loading an executable while paging out
another.

	There are some hidden assumptions here; for example, things are
	slightly different if your compiler or editor are memory based,
	or if your major application is not sw development.

You want to reduce the *instantaneous* load on a disc, not its average one;
and to avoid like taxes copies from a disc to the same disc.

--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk