Multiple partitions on 1 and 2 Unix PC hard disks.

Lenny Tropiano lenny at icus.ICUS.COM
Tue Nov 20 13:45:23 AEST 1990


In article <1990Nov16.033801.978 at shibaya.lonestar.org> afc at shibaya.lonestar.org
(Augustine Cano) writes:
|>In preparation for a 2 stage upgrade, I now seek some net advice.
|>The first stage of the upgrade is to install the large HD I just bought
|>(A priam 519, 1224 tracks, 15 heads, 190 Mb unformatted.)  I would do
[...]
Oooh!  Don't make me jealous!  All that disk space! :-)

|>My original plan is to make 2 partitions of equal size in this new disk:
|>/ and /u.  The pros and cons, as I see them are:

Be careful with partitioning.  While there is some benefit to multiple
partitions on the UNIX PC (if your disk space warrants it) [ie. the
fragmentation problems with some highly-volitile areas] -- the UNIX PC
software wasn't designed with that in mind.  A lot of things break, and
I couldn't give you a list of what will or what won't when you do it,
you'll find out pretty quickly.  

Basically AT&T (or Convergent) didn't keep certain rules in hand, or
didn't plan ahead for the possibility of another partition.  What generally
breaks is something that uses the link(2) system call.  A quick way to
implement a rename() system call is to link() it to another spot and then
unlink() the old -- since the UNIX PC doesn't have one automomic rename()
operation.   Welllll... the problem is link(2) will fail if you cross
filesystem boundaries.  Install scripts are most guilty of this, although
each and everyone could be fixed by using a cp(1) instead of a ln(1).  They
figured it would be faster to just the link, instead of making a duplicate
copy out of the /usr/tmp directory to the installed directory.

Nevertheless, partitions do work. 

/ on /dev/fp002 read/write on Sat Nov 10 15:32:10 1990
/tmp on /dev/fp003 read/write on Sat Nov 10 15:32:10 1990
/usr/spool on /dev/fp004 read/write on Sat Nov 10 15:32:10 1990
/usr/tmp on /dev/fp011 read/write on Sat Nov 10 15:32:10 1990
/netnews on /dev/fp012 read/write on Sat Nov 10 15:32:10 1990
/archives on /dev/fp013 read only on Mon Nov 19 22:15:28 1990

This is course isn't a recommended way of partitioning your disks, it's
just what *I* did.  My reasoning was that /tmp, /usr/spool, /usr/tmp,
my netnews (/netnews) are highly volitile, and it doesn't fragment my
root filesystem too much (which contains /u).

|>Another possibility is to have /tmp as the other partition on
|>the second drive.  This would speed things up, but somehow I feel that a
[...]
If /tmp was on a disk with a higher access/seek rate it might offer
some performance increase.  Of course some programs look at the TMPDIR
environment variable and you can set your /tmp anywhere... but a lot
do not as well.

|>Also, I seem to recall that without re-linking the kernel, you
|>can only have 2 partitions per drive (in addition to /dev/fp000 and
[...]
No, you can have up to 16 partitions (slices) per drive (/dev/fp0[0-1][0-f]), 
of course the NMOUNT (number of mount points) is set to 8 in 3.51m, and 4 
in versions before then.  Remember when you do floppy filesystems, that 
will count for a MOUNT-point if you decide to mount it.  On each disk, the
first partition /dev/fp000 and /dev/fp010 is the boot-information.  That
leaves 15 for user-consumption.  Obviously swap-space would be /dev/fp001,
the second partition on the first disk ... but on the second disk /dev/fp011
doesn't have to be allocated to swap space (in fact it can't...) it is
just another plain 'ole partition...

|>Also, would it do any good to have a swap partition larger than 5000 
> blocks?  (I also plan to add 1.5 Mb RAM to a RAM-less combo board.)

You can run out of swap space depending on the applications and load on
your machine, I have with the generic 5MB of swap space.  I'd recommend
if you have the disk space to spare to increase it accordingly.

Take care!  BTW: Augustine -- we're practically neighbors now! :-)

-L.
-- 
| Lenny Tropiano           ICUS Software Systems        lenny at icus.ICUS.COM |
| ...!{ames,cs.utexas.edu,pacbell}!icus!lenny           attmail!icus!lenny  |
+---------------- 14300 Tandem Blvd #222, Austin, TX 78728 -----------------+



More information about the Comp.sys.att mailing list