bill@mousetrap.canton.mi.us (William S. Johnston) (11/17/90)
I would like to know if installing the swap on another drive will greatly improve the overall performance of A/UX. I would like to install / on a 300 meg drive which runs at 16 ms but put the swap on a separate 40 meg running at approx 15 ms. Am I correct in thinking that when the system needs to access the swapper it just needs to move the r/w heads on the one drive versus if it was on the same drive with the root partition the drive would have to constantly move the heads between the swap partition and root? If so how would I go about installing it in this manner. Any help or recommendations would be greatly appreciated. Thanks in advance.. -- Bill Johnston, N8HQG | bill@mousetrap.canton.mi.us 2127 Glencoe Hills Dr. Apt #8 | Amateur: n8hqg@wa8ooh.mi.us.na Ann Arbor, Michigan 48108-1040 | Macintosh-A/UX-HP48SX-Ham Radio
gerson@parc.xerox.com (Dan Gerson) (11/21/90)
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 where ^D is control-D, and ?? is hex for the SCSI unit number for the disk that the swap partition is on plus 24(decimal). For example, I set swapdev to 0x1e01 since my swap partition is on SCSI unit 6, slice 1, and 6+24=30 which is 0x1e. The trailing 01 is the minor device number, which is 1 for slice 1 (the swap partition). Then reboot. If you don't get swapadd panics, you're ok. If you do, kconfig works in the standalone shell as well. This just modifies your current unix image. The next time you run newconfig or whatever, or maybe even if you change your NuBus slots, the change to SWAPDEV will be smashed. To avoid this, you can also patch /nextunix (or whatever it is called) which I think is the image which gets used when doing an autoconfiguration, as well as some other file whose name escapes me, which is what newconfig uses. Look in /etc/config/ or something like that to find it. It will be the base unix image which it uses.
sramtrc@windy.dsir.govt.nz (11/22/90)
In article <GERSON.90Nov20142613@dupin.parc.xerox.com>, gerson@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@albert.dsir.govt.nz