Xref: utzoo unix-pc.general:6586 comp.sys.att:10973 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!emory!skeeve!ditka!kls From: kls@ditka.UUCP (Karl Swartz) Newsgroups: unix-pc.general,comp.sys.att Subject: Re: Multiple partitions on 1 and 2 Unix PC hard disks. Message-ID: <32084@ditka.UUCP> Date: 28 Nov 90 09:58:22 GMT References: <1990Nov16.033801.978@shibaya.lonestar.org> <1323@icus.ICUS.COM> Followup-To: unix-pc.general Organization: Inaction Central, San Jose, California Lines: 112 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."