jrp@rducky.uucp (JIM PICKERING) (12/03/89)
I started playing with the partition sizes on my second hard disk this weekend. I wanted to decrease the 'swap' partition (partition 1) in order to increase partition 2. I use partition 1 as /tmp and partition 2 as /usr/spool. When formatting the disk, the default is 4000-5000 logical blocks (4-5 meg.). My second disk is only 30 meg. so I would like to have as big as /usr/spool as possible (news really eats disk space). What is a safe size for /tmp? Or what programs use /tmp for a scratch area? I suppose I could set partition 1 to 0 blocks and not mount /tmp. Is there a performance increase with anything (compiler, etc.) by having /tmp on the faster disk? Thanks. jim -- Jim Pickering c/o Technical Solutions || (north) ..csustan!polyslo!rducky!jrp P.O. Box 1045 || (south) ..sdsu!polyslo!rducky!jrp Arroyo Grande, CA 93420 || (south) ..csun!polyslo!rducky!jrp (805) 473-1037 || (east) ..csufres!polyslo!rducky!jrp
jcm@mtunb.ATT.COM (John McMillan) (12/05/89)
In article <1989Dec3.062538.9719@rducky.uucp> jrp@rducky.uucp (JIM PICKERING) writes: > >I started playing with the partition sizes on my second hard disk >this weekend. I wanted to decrease the 'swap' partition (partition 1) >in order to increase partition 2. I use partition 1 as /tmp and >partition 2 as /usr/spool. When formatting the disk, the default >is 4000-5000 logical blocks (4-5 meg.). My second disk is only 30 meg. >so I would like to have as big as /usr/spool as possible (news really >eats disk space). What is a safe size for /tmp? Or what programs use >/tmp for a scratch area? 1) Putting /tmp on a mounted file-system invites trouble. Some Install scripts presume the work area -- under /tmp -- is on the same file-system as the target areas (/bin, /usr/bin, /lib, /usr/lib, etc...). This is fact -- I don't and never did advocate it. Their use of 'ln' instead of 'mv' means they will fail if you run this from a mounted /tmp. 2) Putting /usr/spool on a mounted file-system invites trouble. If I recall correctly, some of that wonderful LP code presumes they can 'ln' the files from wherever to the spool area. I haven't experienced this, but was told so long ago in a distant galaxy. 30 MB! I'd recommend just using it as a spare /u2 [user file] area. I have NOT heard any warnings about mounting /usr/tmp -- if enough of your programs use this it might be worth it. john mcmillan -- att!mtunb!jcm
jbm@uncle.UUCP (John B. Milton) (12/05/89)
In article <1989Dec3.062538.9719@rducky.uucp> jrp@rducky.uucp (JIM PICKERING) writes: >I started playing with the partition sizes on my second hard disk >this weekend. I wanted to decrease the 'swap' partition (partition 1) >in order to increase partition 2. I use partition 1 as /tmp and >partition 2 as /usr/spool. When formatting the disk, the default >is 4000-5000 logical blocks (4-5 meg.). My second disk is only 30 meg. >so I would like to have as big as /usr/spool as possible (news really >eats disk space). What is a safe size for /tmp? Or what programs use >/tmp for a scratch area? > >I suppose I could set partition 1 to 0 blocks and not mount /tmp. Is >there a performance increase with anything (compiler, etc.) by having >/tmp on the faster disk? You bet! I would create an entirely new tmp dir (say /temp or /tmp2), then set the TMPDIR environment variable in /etc/profile. A great many programs use TMPDIR (vi, cc, sort, etc.). If a program uses tmpnam(3S) or tempnam(3S), which ALL programs should, then you can direct tmp use anywhere you want. You can get a lot of speed-up on compiles if you put tmp on a disk not involved in the compile. John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!
lenny@icus.islp.ny.us (Lenny Tropiano) (12/06/89)
In article <1989Dec3.062538.9719@rducky.uucp> jrp@rducky.uucp (JIM PICKERING) writes: |> |>I started playing with the partition sizes on my second hard disk |>this weekend. I wanted to decrease the 'swap' partition (partition 1) |>in order to increase partition 2. I use partition 1 as /tmp and |>partition 2 as /usr/spool. When formatting the disk, the default |>is 4000-5000 logical blocks (4-5 meg.). My second disk is only 30 meg. |>so I would like to have as big as /usr/spool as possible (news really |>eats disk space). What is a safe size for /tmp? Or what programs use |>/tmp for a scratch area? |> [...] I'm following up to this article, even though I read John McMillian's response (jcm@mtunb.att.com) ... In any case, my partitioning is as follows: /archives on /dev/fp013 read only on Wed Dec 6 01:14:27 1989 /netnews on /dev/fp012 read/write on Thu Nov 23 12:02:13 1989 /usr/tmp on /dev/fp011 read/write on Thu Nov 23 12:02:16 1989 /usr/spool on /dev/fp004 read/write on Thu Nov 23 11:50:11 1989 /tmp on /dev/fp003 read/write on Thu Nov 23 11:50:11 1989 / on /dev/fp002 read/write on Thu Nov 23 11:50:11 1989 / (/dev/fp002): 13210 blocks 7126 i-nodes total: 87056 blocks 10880 i-nodes /tmp (/dev/fp003): 5088 blocks 269 i-nodes total: 6000 blocks 288 i-nodes /usr/spool(/dev/fp004): 10946 blocks 7021 i-nodes total: 30000 blocks 7488 i-nodes /usr/tmp (/dev/fp011): 7864 blocks 990 i-nodes total: 8000 blocks 992 i-nodes /netnews (/dev/fp012): 28022 blocks 7791 i-nodes total: 80000 blocks 17488 i-nodes /archives (/dev/fp013): 6764 blocks 4677 i-nodes total: 42944 blocks 5360 i-nodes In any case, I do have /tmp mounted, and have found the problems that exist. Like John said, most of them are things that exploit that point that "ln" works faster than "mv" but never take into account that you _might_ have more than one partition and you can't ln across filesystems. The best solution to this is to "hand-Install" your programs. Or at the very least fix the "Install" script found on the installtion disks and then re-cpio it up to be installed through the UA. Of course you could umount /tmp when you are doing Software Installations. My space for /tmp and /usr/tmp is plenty for what I do. I use /tmp and /usr/tmp for things like big file manipulations, compilations, etc... It's nice to keep some of the filesystems from becoming totally fragmented. I'm sure you can make them smaller, but might not be a good idea to make them too small, it's not fun re-partitioning, take it from someone who has done it a few times... You can get some blocks back by decreasing the number of i-nodes on those partitions (ie. don't use the default "mkfs /dev/fp0nn" command. Use a "mkfs /dev/fp0nn blocks:inodes" I'd increase the i-nodes (like I've done) on the spool or in my case, the /netnews partition. Not only does netnews eat space, it loves i-nodes too. |>I suppose I could set partition 1 to 0 blocks and not mount /tmp. Is |>there a performance increase with anything (compiler, etc.) by having |>/tmp on the faster disk? Also having /tmp on a "faster" disk will increase the performance of compiles, and having /usr/tmp on a "faster" disk will make "sort(1)" a bit better. -- | Lenny Tropiano ICUS Software Systems [w] +1 (516) 589-7930 | | lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 | | {ames,pacbell,decuac,hombre,sbcs,attctc}!icus!lenny attmail!icus!lenny | +------- ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752 -------+
mvadh@cbnews.ATT.COM (andrew.d.hay) (12/06/89)
In article <1049@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes:
[]
"In any case, I do have /tmp mounted, and have found the problems that
"exist. Like John said, most of them are things that exploit that point
"that "ln" works faster than "mv" but never take into account that you
"_might_ have more than one partition and you can't ln across filesystems.
"
"The best solution to this is to "hand-Install" your programs. Or at
"the very least fix the "Install" script found on the installtion disks
"and then re-cpio it up to be installed through the UA.
"
"Of course you could umount /tmp when you are doing Software Installations.
what if you make ksh the standard SHELL for install, and make a .kshrc
file with alias -x ln=mv ?
--
Andrew Hay +------------------------------------------------------+
42 Authority | Zaphod Beeblebrox is now appearing in |
AT&T-BL Ward Hill MA | "No S*x Please, We're Amoeboid Cingatularians" |
a.d.hay@att.com +------------------------------------------------------+madcat@cbnewsm.ATT.COM (Marty Donaldson) (12/07/89)
From article <1049@icus.islp.ny.us>, by lenny@icus.islp.ny.us (Lenny Tropiano): > that "ln" works faster than "mv" but never take into account that you > _might_ have more than one partition and you can't ln across filesystems. > > The best solution to this is to "hand-Install" your programs. Or at > the very least fix the "Install" script found on the installtion disks > and then re-cpio it up to be installed through the UA. I ran into this software install problem also. I did the following: 1) renamed ln to ln.REAL 2) wrote a shell script called ln, which: a) does an ln.REAL. b) checks the exit code of the ln.REAL. c) if ln.REAL was successful, exit. d) if ln.REAL was unsuccessful (cross fs ln), do a cp instead with the same args., exit. I have /tmp and /usr on the 2nd drive. This has not failed me so far. I would have included the actual shell script but its at home on a system that's not cooperating with a 2meg mother board upgrade. I'll see if I can locate a backup copy and post it.
jcm@mtunb.ATT.COM (John McMillan) (12/08/89)
In article <12028@cbnews.ATT.COM> mvadh@cbnews.ATT.COM (andrew.d.hay,54242,wi,1d007,508 374 5484) writes: : >what if you make ksh the standard SHELL for install, and make a .kshrc >file with alias -x ln=mv ? : 1) Replacing SH with KSH is a serious breach of sanity. KSH is ALMOST a superset of SH -- but the differences are VERY REAL. It can waste hours or days for support people when folks play this game. 2) Now let's see, Andy: ln vi /usr/bin/vi ln vi /usr/bin/view ln vi /usr/bin/ex ln vi /usr/bin/vedit ... How does that work, again? john mcmillan -- att!mtunb!jcm -- muttering for self
rjg@sialis.mn.org (Robert J. Granvin) (12/08/89)
In article <1717@mtunb.ATT.COM> jcm@mtunb.UUCP (John McMillan) writes: >In article <12028@cbnews.ATT.COM> mvadh@cbnews.ATT.COM (andrew.d.hay,54242,wi,1d007,508 374 5484) writes: >>what if you make ksh the standard SHELL for install, and make a .kshrc >>file with alias -x ln=mv ? > >1) Replacing SH with KSH is a serious breach of sanity. > KSH is ALMOST a superset of SH -- but the differences are VERY > REAL. It can waste hours or days for support people when folks > play this game. Not the mention the ongoing babble several months ago... ksh and sh differ in even the ways they handle errors. If sh hits a line that blows off, the whole script blows off at that point, and you stop. If ksh hits a line that blows off, it feels the pain and loss, but continues on happily through the script. If your script _relies_ on the fact that it will fail if a line fails, imagine the damage potential if it doesn't (And yes, there are many like it). -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ BITNET: rjg%sialis.mn.org@nic.mr.net __National Information Services__ UUCP: ...amdahl!bungia!sialis!rjg "Insured against Aircraft, including self-propelled missiles and spacecraft."