afc@shibaya.lonestar.org (Augustine Cano) (11/16/90)
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
everything at the same time, but John's HD2 board is not shipping yet.
I already have a WD2010 and the P.51 option installed.
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:
Pros: 1 - /u sees most of the disk activity, but being a separate
partition, will not mess up /. Since it can be dismounted, it
can be unfragmented easily with packdisk.
2 - / and /u will be large enough that they won't fill up immediately.
Cons: 1 - /usr/spool, which sees lots of disk activity, will temporarily
be messing up the / partition.
2 - activity in /tmp will also somehow fragment the root partition.
3 - having / and /u on the same disk would make for lots of head
movement. However, would this be any worse than the standard,
one-partition per drive, unix pc way of doing things?
4 - /usr/lib/news, with all its updating of log files, history
files and active file would fragment the root partition some.
I suspect, though, that giving /usr/lib/news its own partition
wouldn't be a good idea.
Later, when I get the HD2 board, I'll add the current drive (an ST-4096)
as drive 2. This drive will also be partitioned in 2 equal chunks,
roughly 40 Mb each. One will be /usr/spool and the other will remain
as a mostly empty space for backups, archives, or semi-permanent temporary
storage.
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
40 Mb /tmp is excessive. How big should /tmp be, if it gets its own
partition? I have stuffed some pretty big things in /tmp before and it was
nice to have all the free space on the drive available, so maybe the speed
penalty of having /tmp in the / partition is worth it. Comments?
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
/dev/fp001), is this correct? Does this also apply to the second drive,
without a swap 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.)
At this point the pros and cons, as I see them now are:
Pros: 1 - /usr/spool will now have its own partition on the slower drive,
thus no longer fragmenting /.
2 - there will be plenty of space (~75 Mb) in / for /usr/man,
/usr/doc, /usr/src/, /usr/lbin, /usr/local and all the other
standard directories that don't change very often.
3 - if the 2nd drive quits, I can just dismount it, re-make
/usr/spool in the root partition and I'm in business again.
This is partially why I'd rather keep /u on the main drive
(size and speed (22 vs 28 ms) are the main reasons).
If the big drive quits, I'm in trouble :-)
Cons: 1 - like 2, 3 and 4 above, depending on where /tmp is put.
But is there really a disadvantage to having 2 drives and lots
of space? :-)
Opinions anyone? Those of you who have 2 HDs and/or multiple partitions,
how did you do it? Any other considerations I have overlooked? Have any
benchmarks been run on different partitioning schemes and what directories
were placed where? Will some programs be broken by the multiple partitions?
Which ones?
I'll post a summary of e-mail responses. However, posting might be
appropriate, since at least the participants in the big HD group buy would
benefit.
Thanks.
--
Augustine Cano INTERNET: afc@shibaya.lonestar.org
UUCP: ...!{ernest,egsner}!shibaya!afcmvadh@cbnews.att.com (andrew.d.hay) (11/19/90)
In article <1990Nov16.033801.978@shibaya.lonestar.org>, afc@shibaya.lonestar.org (Augustine Cano) writes: > In preparation for a 2 stage upgrade, I now seek some net advice. [] > Cons: [] > 3 - having / and /u on the same disk would make for lots of head > movement. However, would this be any worse than the standard, > one-partition per drive, unix pc way of doing things? somewhat. with one partition, you have |---FILES---|-----FREESPACE-----| with two, it's |files|freespace|files|freespace| thus involving (slightly) longer seeks. however, see comment on thrashing below. [] > 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 > 40 Mb /tmp is excessive. How big should /tmp be, if it gets its own > partition? I have stuffed some pretty big things in /tmp before and it was > nice to have all the free space on the drive available, so maybe the speed > penalty of having /tmp in the / partition is worth it. Comments? i don't think /tmp should be larger than 16M; probably 8 would be enough. > 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 > /dev/fp001), is this correct? Does this also apply to the second drive, > without a swap 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 have up to 16 partitions per drive (including swap and boot), but the kernel mount table is only 4 entries long. THIS INCLUDES THE FLOPPY! if you run a lot of programs at once (or big ones), there is a benefit in a larger swap space. when swap is full, the next process to swap out gets dropped on the floor. [] > Opinions anyone? Those of you who have 2 HDs and/or multiple partitions, > how did you do it? Any other considerations I have overlooked? Have any > benchmarks been run on different partitioning schemes and what directories > were placed where? Will some programs be broken by the multiple partitions? > Which ones? we have a lot of 2-drive unix machines here. they're partitioned thusly: / and users (/u on the 3b1) on drive 1, and /usr and /tmp on drive 2. one goal: make root a static filesystem; remove all directories that thrash to mounted filesystems. another goal: balance filesystem activity across both drives. one program that will break is install software; it uses mv to shift files out of /tmp. of course, mv could be fixed (on my list of things-to-do) to work across filesystems... -- Andrew Hay +------------------------------------------------------+ Ragged Individualist | You just have _N_O idea! It's the difference | AT&T-BL Ward Hill MA | between _S_H_O_O_T_I_N_G a bullet and _T_H_R_O_W_I_N_G it! | a.d.hay@att.com +------------------------------------------------------+
lenny@icus.ICUS.COM (Lenny Tropiano) (11/20/90)
In article <1990Nov16.033801.978@shibaya.lonestar.org> afc@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@icus.ICUS.COM | | ...!{ames,cs.utexas.edu,pacbell}!icus!lenny attmail!icus!lenny | +---------------- 14300 Tandem Blvd #222, Austin, TX 78728 -----------------+
kls@ditka.UUCP (Karl Swartz) (11/28/90)
In article <1323@icus.ICUS.COM> lenny@icus.ICUS.COM (Lenny Tropiano) writes: >In article <1990Nov16.033801.978@shibaya.lonestar.org> afc@shibaya.lonestar.org >|>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: You can probably do better with some careful thought and tuning, but there are risks. >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. In particular, many systems have a minimal / or root partition, just enough to boot the system, then a larger /usr partition that is needed for normal system operation but not for a minimal boot. This makes a lot of sense, but there's stuff in /usr that the UNIX PC wants to have long before you'd get around to mounting any partitions, so don't try this trick. The other major gotcha is with installations that try to link to /usr from /tmp, assuming you mount /tmp. Fortunately this is a simple task of unmounting /tmp for the duration of any software installs. >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 Yup, and mine looks quite similar: / on /dev/fp002 read/write on Sun Nov 18 13:26:55 1990 /tmp on /dev/fp011 read/write on Sun Nov 18 13:27:07 1990 /usr/spool on /dev/fp004 read/write on Sun Nov 18 13:27:43 1990 /u on /dev/fp003 read/write on Sun Nov 18 13:29:25 1990 /u2 on /dev/fp005 read/write on Sun Nov 18 13:30:18 1990 /usenet on /dev/fp012 read/write on Sun Nov 18 13:31:04 1990 My /archives is called /u2, and I keep /u separate but not /usr/tmp. These latter two deserve comment. First, I occasionally login as install, and somewhere along the way this got bent out of shape when it found it wasn't in the root partition. I solved this by moving install's home directory to /ua.install. /usr/tmp isn't so easy. I initially 5 MB each for /tmp and /usr/tmp. After seeing some weird behavior with news history files, I realized that the 5 MB in /usr/tmp was not enough scratch space for sort when doing a Usenet expire. But I didn't want to reduce the size of /tmp. The only significant use of /usr/tmp was sort, so it seemed to try to move sort's scratch area to /tmp and switch to a 10 MB /tmp without any special space for /usr/tmp. (I ended up using only 7.6 MB for the merged /tmp partition.) To do this I found I had to patch the sort executable, which I did as follows: # cd /bin # cp sort sort.usrtmp # adb -w sort > 0x90440?s 90440: /usr/tmp > 0x90440?W '/tmp' > 0x90444?w 0x74 > ^D # >|>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.) I've found it very easy to outstrip that rather paltry allocation, so increasing swap space is now one of the first things I do on a UNIX PC. Anyway, ditka has a Maxtor XT-2190 as drive 0 and the original MiniScribe 6085 as drive 1, with partitioning as follows: drive partition blocks inodes filesystem 0 0 120 - (VHB) 1 9,000 - (swap) 2 42,000 10,496 / 3 36,000 8,992 /u 4 16,200 4,048 /usr/spool 5 43,560 10,880 /u2 1 0 64 - (VHB) 1 7,680 1,920 /tmp 2 57,792 24,000 /usenet VHB is the Volume Home Block, which contains the drive partition table, bad block table, and perhaps a loader. The intent of the distribution of files was to spread the load of news activity over both drives (note that /usr/lib/news ends up on drive 0) and to restrict the second drive to fully expendable information. Also, I wanted to minimize seeking on drive 0, so /u2 (archival storage) is out of the way, and /usr/spool is a bigger seek than /u from the executables which is probably better for my purposes. I also gave /usenet (the partition used to hold news articles) roughly twice as many inodes as the default, using the following command: /etc/mkfs /dev/rfp012 115584:24000 1 128 In retrospect, I'd give serious consideration to putting /usr/lib/news, or at least the history files, in a separate partition, as this tends to fragment its home fairly quickly. Otherwise, this arangement has served my needs well. -- Karl Swartz |UUCP {uunet,decwrl}!daver!ditka!kls 1-408/223-1308 |INet kls@ditka.chicago.com |Snail 1738 Deer Creek Ct., San Jose CA 95148 "It's psychosomatic. You need a lobotomy. I'll get a saw."