dave@murphy.UUCP (The Giant Hogweed) (07/03/87)
Does anyone still need /usr/tmp? This is one of those things that date
back to the days when you had two 5M drives; one was root and the other
was /usr, and neither one had a lot of space, so they both had temp
directories, and some utilities used /tmp and some used /usr/tmp.
Things are different now. Around here, practically every machine has
a /tmp partition with a fair amount of space. Unfortunately, a lot of
people have neglected /usr/tmp, especially those that have moved /usr/spool
and /usr/man/cat* off to other places; a lot of these machines have almost
no free space on /tmp. This becomes a problem when you try to do a sort,
because the sort utility creates its work files on /usr/tmp.
On everything that I take care of, I've made /usr/tmp a symlink to
/tmp (Sun and Gould machines, obviously running derivatives of BSD 4.2
and 4.3). Several others have done the same.
So, my question is: Does anyone still need /usr/tmp? Is there any reason
why all the utilities that use it couldn't be recoded to use /tmp instead,
and /usr/tmp be banished?
---
"Country beats the hell out of me" -- Jerry Dale McFadden
Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
[Ignore header, mail to these addresses]
UUCP: ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt
or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt
ARPA: dcornutt@gswd-vms.arpa
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."guy%gorodish@Sun.COM (Guy Harris) (07/03/87)
> Is there any reason why all the utilities that use it couldn't be recoded > to use /tmp instead, and /usr/tmp be banished? Yes. If by "utilities" you mean the programs supplied as part of UNIX by the vendor, changing the utilities isn't good enough. There will be lots of third-party and customer-written applications out there that use "/usr/tmp", and they'd all have to change too. When I was at CCI we were porting our Office Power application to a Zilog S8000, and one of the bits of Zilog B****n D*****e was that it didn't have a "/usr/tmp". Our applications put things in "/usr/tmp" because it was more likely to have lots of room than "/tmp". Our solution was simple: % su Password: # mkdir /usr/tmp # chmod a+rwx /usr/tmp Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy CINorNorNnli
pdb@sei.cmu.edu (Patrick Barron) (07/03/87)
In article <431@murphy.UUCP> dave@murphy.UUCP (The Giant Hogweed) writes: >On everything that I take care of, I've made /usr/tmp a symlink to >/tmp (Sun and Gould machines, obviously running derivatives of BSD 4.2 >and 4.3). Several others have done the same. > >So, my question is: Does anyone still need /usr/tmp? Is there any reason >why all the utilities that use it couldn't be recoded to use /tmp instead, >and /usr/tmp be banished? This is just the opposite of my situation. I'm running off a single 380 megabyte disk that only has three partitions - /, /usr, and swap. I have about 600 blocks free on the root partition, but lots of space on /usr, so I run with /tmp symlinked to /usr/tmp (if I have to come up single-user or something like that, I remove the /tmp link and make a real directory). Myself, I'd prefer to see everything use /usr/tmp. Actually, ordinarily, I don't care. But when 'pc' tried to create a couple of 1+ megabyte temporary files (as it did when I tried build TeX from its WEB source), I *really* wanted the files created where I had space. However, in principle, I agree: there should be one place where temporary files are created. If you want it to be /tmp, then recode all the utilities to use /tmp (or better, edit all the binaries with EMACS or something, and globally replace all occurances of "/usr/tmp" with "/tmp\0\0\0\0" :-) ). --Pat.
isns01@ms3.UUCP (Jim Chappell) (07/03/87)
In article <431@murphy.UUCP>, dave@murphy.UUCP (The Giant Hogweed) writes: > Does anyone still need /usr/tmp? This is one of those things that date > back to the days when you had two 5M drives; one was root and the other > was /usr, and neither one had a lot of space, so they both had temp > directories, and some utilities used /tmp and some used /usr/tmp. I thing /tmp is best used for really transient stuff -- things that wouldn't be missed missed in a crash recovery. /usr/tmp sould be used for temporaries with a little longer life span -- say document images that can safely be removed after a day or two of unuse. Generally, it makes sense to size your file system to its anticipated use even if you have relatively unlimited disk space. -- Jim Chappell ...!seismo!vrdxhq!ms3!jrc ISN Corp. (703) 979-8900 1235A Jeff Davis Hwy, Suite 220 Arlington, Va 22202
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/06/87)
In article <431@murphy.UUCP> dave@murphy.UUCP (The Giant Hogweed) writes: >Does anyone still need /usr/tmp? YES!!! >Things are different now. Around here, practically every machine has >a /tmp partition with a fair amount of space. Not around here! Our /tmps typically run around 15Mb, which sounds like a lot until you try sorting a few large files or creating several frame buffer images. The idea is, /tmp should be used ONLY by "system" utilities, and /usr/tmp should be used by "user" applications, particularly those that might need a lot of space; it is not wise to allow user applications to break the operation of system utilities. That is why the default for tempnam() in the absence of a TMPDIR environment variable is usually set to /usr/tmp.
dgk@ulysses.homer.nj.att.com (David Korn[eww]) (07/06/87)
In article <6064@brl-smoke.ARPA>, gwyn@brl-smoke.UUCP writes: > In article <431@murphy.UUCP> dave@murphy.UUCP (The Giant Hogweed) writes: > >Does anyone still need /usr/tmp? > With a system that does distributed computing you might want to consider using separate /tmp on each host and a single shared /usr/tmp. For example, the script foo > /usr/tmp/file$$ bar /usr/tmp/file$$ would be guaranteed to work even if foo and bar execute on separate nodes but foo > /tmp/file$$ bar /tmp/file$$ would not since /tmp is allowed to be different on different nodes. Of course you need a shell that generates a unique $$ over the network. David Korn {ihnp4|attunix|seismo}!ulysses!dgk
rbj@icst-cmr.arpa (Root Boy Jim) (07/07/87)
This is just the opposite of my situation. I'm running off a single 380 megabyte disk that only has three partitions - /, /usr, and swap. I have about 600 blocks free on the root partition, but lots of space on /usr, so I run with /tmp symlinked to /usr/tmp (if I have to come up single-user or something like that, I remove the /tmp link and make a real directory). You don't have to. In single user mode (/usr not mounted), mkdir /usr/tmp. The symlink will work in both cases. When running multiuser, the single user copy will be hidden. BTW, I would recommend splitting that big /usr partition into more pieces. It gives you more flexibility. --Pat. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 What I want to find out is -- do parrots know much about Astro-Turf?
ignatz@aicchi.UUCP (07/10/87)
There are several reasons to keep both /tmp and /usr/tmp. First, all programs that expect one or the other will break. Period. And, it not being the 'good old days' of everybody and their dog having a source license, this would end up causing people just recreating the missing directory. Another item is to consider another reason there's a /tmp in the first place. Often, "/usr" is a separately mounted filesystem. This means, of course, that sometimes--usually in single-user mode--somebody--usually, the administrator--will run the system with some, or all, filesystems dismounted. Now, where would they be if all they had was "/usr/tmp" on a mounted filesystem, which now wasn't? Ok, you say; put both /tmp and /usr/tmp on the root filesystem. Well, you could...but why waste that much space on the what is usually a fairly static filesystem? Also, with the system expecting to use /tmp, and all the rest of the world in /usr/tmp, when John Q. Bozo uses all the space on the "/usr/tmp" filesystem, the kernel won't be left out in the cold with the other users... All in all, then, there are several reasonable arguments for just keeping the two as is. If you want to do links and such, fine; but it is something that you can control locally, and judge the pros and cons of your action. -- Dave Ihnat Analysts International Corporation (312) 882-4673 ihnp4!aicchi!ignatz || ihnp4!homebru!ignatz