phil@qfdts.OZ (Phil Chadwick) (05/07/87)
The other day we lost a disk and during those tedious hours it took to rebuild a usable system, I got to thinking... On the day I first booted UNIX from release tape, root, swap, tmp and usr were placed on the disk starting at cylinder 0. Even though we (normally) have three disks and the important files systems are now distributed over multiple drives, the original file system layout concept is largely unchanged. For optimal average access time, important file systems should reside in the mid-range cylinders of a disk. So why are our disks still arranged with the most important (and subjectively, the heaviest) access biased around the lowest cylinder numbers? I am giving serious consideration to rearranging the larger disks (say those > 300Mb) with root, tmp, swap and usr (not including users' files) fair bang in the middle. I can think of only one significant disadvantage: available space will be fragmented into two disjoint areas, however the bigger the disk the smaller the problem. Any comments? Phil Chadwick
brian@scgvaxd.UUCP (05/22/87)
In article <1294@qfdts.OZ> phil@qfdts.OZ (Phil Chadwick) writes: >On the day I first booted UNIX from release tape, root, swap, >tmp and usr were placed on the disk starting at cylinder 0. > >For optimal average access time, important file systems should >reside in the mid-range cylinders of a disk. So why are our >disks still arranged with the most important (and subjectively, >the heaviest) access biased around the lowest cylinder numbers? > >I am giving serious consideration to rearranging the larger >disks (say those > 300Mb) with root, tmp, swap and usr (not >including users' files) fair bang in the middle. > >Any comments? Well, actually, some people have shifted the 'a' and 'b' partitions to the middle of the disk for precisely this reason. On Sequent Computers, drives on their new dual channel disk controller (eagles and swallows) have partitions laid out as follows (not to scale): --------------------------------------------------------------------------- | h |a| b | g | --------------------------------------------------------------------------- | d | e | --------------------------------------------------------------------------- | c | --------------------------------------------------------------------------- i.e., you can run partitions h,a,b & g or d & e or just c. I've found this partition layout to be doublely advantageous in that your 'user-files only' disks don't need to have wasted tiny 'a' & 'b' partitions on them. If you want to change the partition sizes yourself on whatever system you have, it's not too difficult if you have source. Just modify the tables in the driver and in /etc/disktab (the latter so newfs knows what you did). On a related performance issue, if you have three or more disks, you should also put root, tmp, and usr on separate disks. And have multiple swap areas. --Brian {seismo,allegra,ihnp4}!scgvaxd!brian
mouse@mcgill-vision.UUCP (05/31/87)
In article <755@scgvaxd.UUCP>, brian@scgvaxd.UUCP (Brian Zill) writes: > In article <1294@qfdts.OZ> phil@qfdts.OZ (Phil Chadwick) writes: >> On the day I first booted UNIX from release tape, root, swap, tmp >> and usr were placed on the disk starting at cylinder 0. [>> about how they should be in the middle of the disk] >> I am giving serious consideration to rearranging the larger disks >> (say those > 300Mb) with root, tmp, swap and usr (not including >> users' files) fair bang in the middle. > Well, actually, some people have shifted the 'a' and 'b' partitions > to the middle of the disk for precisely this reason. > If you want to change the partition sizes yourself on whatever system > you have, it's not too difficult if you have source. Just modify the > tables in the driver and in /etc/disktab [...] All of this is ignoring an issue. How do you boot from such a disk? Clearly the boot block must still be at sector zero, where the boot ROMs expect it to be. The level-zero boot *can* be anywhere, but the gain of relocating it is probably not worth the pain. But you will have to change the partition tables in the standalone drivers for the level-zero boot if /boot is to reside on a partition beginning not at sector zero or with a size not equal to the usual partition-at-sector-0 size; and you will have to change the partition tables in /boot if the root partition is on such a partition. This is probably why the distribution extracts itself this way. I for one am glad it does it the way it does. We have a MicroVAX here with a disk that claims (to the driver) to be an RA81. Unfortunately, it is not an RA81; it is much smaller than a real RA81. As a result, if the distribution driver had tried to put root and swap in the middle of the disk, it would have had no hope of succeeding. As it was, the miniroot ran fine, then on the real root I used adb to patch the partition tables in the vmunix there, so I could mkfs and extract the real /usr, and then of course I just changed the driver and rebuilt. No need to change the level-0 boot or /boot because the root partition is still the one beginning at offset 0. Actually, if you can spare a half-megabyte or more of core, you may want to consider putting /tmp on a silicon disk. If you are running 4.3BSD on a VAX, or Sun UNIX 3.0 (probably later versions as well) on a Sun-3 (probably on a Sun-2 as well), I have a silicon disk driver for you. (Everyone else is welcome to it as well, but I have no reason to believe it'll be useful to you.) Think this over before doing it, or watch performance carefully before-and-after, because the silicon disk driver will be taking memory you are likely to find you need worse for other things. I also have another pseudo-disk driver. This one takes a normal file and makes it appear to be a disk partition, mapping requests for block N of the parition into filesystem access to block N of the file. It runs under 4.2 and 4.3 BSD, but not under Sun UNIX and only very unreliably under 4.3+NFS (the mtXinu version). der Mouse (mouse@mcgill-vision.uucp)
rbj@icst-cmr.arpa (06/02/87)
Well, actually, some people have shifted the 'a' and 'b' partitions to
the middle of the disk for precisely this reason. On Sequent Computers,
drives on their new dual channel disk controller (eagles and swallows)
have partitions laid out as follows (not to scale):
---------------------------------------------------------------------------
| h |a| b | g |
---------------------------------------------------------------------------
| d | e |
---------------------------------------------------------------------------
| c |
---------------------------------------------------------------------------
i.e., you can run partitions h,a,b & g or d & e or just c. I've found this
partition layout to be doublely advantageous in that your 'user-files only'
disks don't need to have wasted tiny 'a' & 'b' partitions on them.
If you want to change the partition sizes yourself on whatever system you
have, it's not too difficult if you have source. Just modify the tables in
the driver and in /etc/disktab (the latter so newfs knows what you did).
--Brian
{seismo,allegra,ihnp4}!scgvaxd!brian
Source is not necessary. The name of the partition tables in 4BSD is
DISK_sizes, where DISK is replaced by whatever you have. In DYNIX, it
is singular. Try `strings /*nix | grep _size' and look for things like
`eagle_size, rm03_sizes, cdc####_sizes, etc. The tables are an array of
eight structures of two ints apiece. The first int is the number of
sectors and the second is the starting *cylinder*.
ADB works quite well under 4BSD and DDT works nicely under DYNIX, altho
you have to invoke the latter twice, once for the running system and
once for the one on disk. You can do this while the system is running
as long as you don't change things too radically.
One last thing. I always boost the kernel's idea of the `a' partition
to overlap the `b' partition as well. That way I can make a combination
file system using the -s option on newfs.
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
Does someone from PEORIA have a SHORTER ATTENTION span than me?jerry@oliveb.UUCP (Jerry F Aguirre) (06/26/87)
Regarding putting the root and swap in the middle of the disk to reduce
seek time. Back in our PDP/11 days we used to run that way. Our disk
layout looked like:
| /usr |root|swap| /u1 |
The bootstrap at sector zero was unchanged, /boot was moved to
/usr/boot and modified to use the new partitions.
In normal usage everything booted and ran fine. Manual booting required
typing in "hp(0,magic_number)unix" where magic_number was to offset to
the root partition. I suppose an alternative would be to duplicate the
kernal on / and /usr. You could then boot from the first partition but
the kernal would still make the middle partition the root. This could
get confusing if you updated one but not the other.
This was a real advantage on the PDP11 because forks were implemented
using a swap. The typical process would execute from /bin and then get
swapped, lots of IO to the root and swap.
If your application is disk intensive then a root and swap in the middle
configuration would probably be worth it. Of course adding more memory
and buffers will reduce both root access and swapping. I suggest that
you do some measurements before going thru the extra hassle.
Jerry Aguirreroy@phri.UUCP (Roy Smith) (06/28/87)
In article <1618@oliveb.UUCP> jerry@oliveb.UUCP (Jerry F Aguirre) writes: > Regarding putting the root and swap in the middle of the disk [...] an > alternative would be to duplicate the kernal on / and /usr. You could > then boot from the first partition but the kernal would still make the > middle partition the root. This could get confusing if you updated one > but not the other. We did something similar when we went from 4.2 to 4.3; we left our 4.2 root where it was and stole the /tmp partition to put the 4.3 root on. We had copies of both kernels on both roots, with 4.3 having a hacked-up partition table. If 4.3 bombed (which it did a lot until we got our act together) we could back out easily. We ran that way for a few weeks. It worked fine, but yes, it was confusing as hell. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016