Swap Partition Location

[sramtrc at windy.dsir.govt.nz]

In article <GERSON.90Nov20142613 at dupin.parc.xerox.com>, gerson at parc.xerox.com (Dan Gerson) writes:
> I have a machine with both A/UX 2.0 and A/UX 1.0.1 on it (we needed to keep
> the latter around since some applications don't work with 2.0).  So, rather
> than duplicate the swap partition, I've reconfigured A/UX 2.0 to use the
> swap partition on A/UX 1.0.1's disk.
> 
> To do this, change the SWAPDEV word in your unix image to tell it what device
> and slice to use.  For example, say (either in the standalone shell or when
> logged in as root):
> kconfig
> SWAPDEV = 0x??01
> ^D

I don't think that this is a good idea. It makes your system more difficult
to maintain (your kernel is now specific to your configuration - change the
drives and you have to change to kernel; the change is undocumented - what
happens if you get run over by a bus and someone else has to take over; and
you have a nonstandard kernel which means that when you get A/UX 2.?? you
will have to do the patch all  over again; etc etc).

Much better is to put an entry into your /etc/fstab to tell the system where
to find the swap partition. See the man for swap(1m) for details.

As for the swap-partition/head-seeking argument I would say "try it and see".
I once played with this idea when deciding where to place my /tmp partition.
The idea is that when doing compiles, having /tmp (and /usr/tmp) on a
separate drive should minimise seeking. I had a Wren and a slower Quantum
and found that it was slightly faster to have everything on the Wren. If
there was any speed advantage from having overlapping seeks using two drives
it was more than compensated for by the faster speed of the Wren.

There are two caveats: I was using A/UX 1.1. Things may be different with
the ufs filesystem. Secondly, there is a bug in the 1.1 and 2.0 generic disk
driver. It doesn't sort the seeks into numerical order as it should (it
uses disksort wrongly) so when there is a queue of seeks for seperate
partitions it should do all those seeks in one partition then move to the
next to do the seeks there. But it does seeks in a random order (actually
they are sorted by blocksize, not block location) so may cover a lot of
extra distance unnecessarily. In practice this may not make a
difference when using the swap partition since I don't think much seeking
is done. I have a patch for the bug and it doesn't make much difference
because most of the time the seek is very short. Only when doing a sync is
it long.

Tony Cooper
sramtrc at albert.dsir.govt.nz