phil@amd70.UUCP (Phil Ngai) (03/18/84)
At the risk of exposing my profound ignorance, why are there both
/tmp and /usr/tmp? When would I use one or the other when I write
a program? Is the distinction between an always mounted and not
always mounted filesystem?
--
Phil Ngai (408) 988-7777 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!philfair@dual.UUCP (Erik E. Fair) (03/19/84)
All of the UniSoft ports of UNIX have no /usr/tmp. Everything goes into
/tmp. On Berkeley systems, typically /tmp is cleared out at reboot, but
/usr/tmp is left alone (i.e. you can leave things in there for extended
periods of time). I don't know the beginnings of the split, unfortunately.
Erik E. Fair
dual!fair@Berkeley.ARPA
{ihnp4,ucbvax,cbosgd,decwrl,amd70,fortune,zehntel}!dual!fair
Dual Systems Corporation, Berkeley, Californiadave@utcsrgv.UUCP (Dave Sherman) (03/19/84)
The existence of /tmp and /usr/tmp is a throwback to older versions
of UNIX (v6 and prior); I believe "user" programs (the same ones that
went into /usr/bin, which was originally publicly writable!) used
/usr/tmp. Nowadays /tmp is normally used by all programs (or it
should be, anyway).
Dave Sherman
Toronto
--
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!davethomson@uthub.UUCP (Brian Thomson) (03/19/84)
I always thought the rationale was that /tmp and /usr/tmp could be
on different head assemblies, avoiding seeks for programs that
read one temp file and write another.
--
Brian Thomson, CSRG Univ. of Toronto
{linus,ihnp4,uw-beaver,floyd,utzoo}!utcsrgv!uthub!thomsonrcd@opus.UUCP (03/19/84)
<>
The split between /tmp and /usr/tmp is in the same spirit as the split
between /bin and /usr/bin. Essentially, you may have some small, fast
disks and some larger, slower ones - so you put the more important but
smaller stuff in /tmp. Depending on the state of your manual pages,
hier(7) will at least suggest this answer. I don't know of anyplace where
it is stated that /tmp and /usr/tmp differ in "permanence" - and I would
suggest that it would be very unwise to count on anything in either place
lasting beyond one terminal session (i.e., remaining after you log out).
It's hard to give even a ballpark guide to how big a file can get before it
should be put in /usr/tmp rather than /tmp, but I'll submit (at the risk of
getting flamed mercilessly) that if it's under 10Kb, /tmp is fine; if it's
over a couple hundred Kb it better be in /usr/tmp. The consequences of
running out of space in /tmp are sufficiently unpleasant not to betaken
lightly.
If you have only one chunk of disk for temporary storage, try to arrange so
that you still have both /tmp and /usr/tmp, to avoid breaking programs you
may receive. (This can be messy - if you don't have symbolic links, it
means that /tmp and /usr/tmp have to be in the same filesystem, which
leaves you with all of /usr in /.)
--
{hao,ucbvax,allegra}!nbires!rcdhenry@utzoo.UUCP (Henry Spencer) (03/20/84)
Brian is close. As I understand it, the reason for the /tmp-/usr/tmp
split is identical to the reason for the /bin-/usr/bin and /lib-/usr/lib
splits, and is a historical accident of hardware configuration at the
Research system.
At one time (circa the time of the original Unix paper in CACM), the
Research machine was a 45 with a fixed-head disk, some RK05s, and an RP03.
The root went on the fixed-head disk, since the absence of seek times
made it fast. But fixed-head disks (anybody remember them?) were *tiny*.
Two megabytes [sic] was a big fixed-head disk. So you had to be fairly
careful to avoid overflowing the root file system (which included /tmp --
it wasn't a separate filesystem). /usr, on the other hand, was the main
filesystem on the 40-MB RP03.
So you had a very sharp split of hardware: things directly under "/",
like /tmp, /bin, and /lib, were fast but had to be small; things under
/usr could be big but accesses to them were slower. So you put the
heavily-used commands in /bin, the heavily-used libraries in /lib, and
[flourish of trumpets] the small temporary files in /tmp. All the other
slush went under /usr, including a /usr/tmp directory for big temporaries.
This is why a few programs like sort(1) put their temporaries in /usr/tmp:
they expect them to be big.
In practice, fixed-head disks are historical relics now, and much of the
justification for the various /x-/usr/x splits has disappeared. There is
one reason why you might retain a /tmp-/usr/tmp split, however. If your
/tmp filesystem is kept in "RAM disk" or something similar for speed,
you might want to keep your editor tempfiles somewhere else if your editor
has crash recovery. Crash recovery definitely works better when the files
it is looking for are kept in non-volatile memory!
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrygwyn@brl-vgr.ARPA (Doug Gwyn ) (03/21/84)
/tmp is usually fast but rather small, /usr/tmp is better for large temp files such as those used by rasterizers. The library routines described in TMPNAM(3S) use P_tmpdir defined in <stdio.h>, usually /usr/tmp. The tempnam() function is especially nice in that it lets one change the temp file directory at runtime via an environment variable $TMPDIR. I encourage everyone to use tempnam().
paul@uiucuxc.UUCP (03/21/84)
#R:amd70:-443200:uiucuxc:29300010:000:561
uiucuxc!paul Mar 20 23:20:00 1984
In regard to the /tmp /usr/tmp split:
Back in the days of V6 on a PDP 11/50, /usr/tmp held the temp files
for the C/A/T 8 phototypesetter. I think this was done for space
reasons. Troff created rather large output files that would overflow
/tmp (which was part of the root filesystem). Filling up the root was
an unkind thing to do to V6 - but I loved V6 anyway.
Paul Pomes
uucp: {decvax,ihnp4,pur-ee,ucbvax}!uiucdcs!uiucuxc!paul
US Mail: Paul Pomes, University of Illinois
1304 W Springfield, Urbana, IL 61801
Phone: 217-333-6262paulsc@tekecs.UUCP (Paul Scherf) (03/21/84)
I am not very good at mind reading, so I can't tell you why /tmp and /usr/tmp were first created, but there are (used to be) systems where everything didn't fit on one device (disk, filesystem, partition, whatever) and all the users' files did fit on one device (disk, filesystem, partition, whatever). On such systems /usr/tmp would be on the same device as all user files, but /tmp would not. The mv command can avoid copying a file if the target location is on the same device. This way the window of vulnerability to system crashes could be made much smaller for programs that need an "atomic" file update (i.e. you want either the old version or the new version of a file, but not part of each or neither, so you can restart after a crash by rerunning the updating program). The schema is: Do a bunch of stuff to create the new version of the file in /usr/tmp/new$USER and take your time. ... mv /usr/tmp/new$USER file Unfortunately many systems are too big to put all the users' files on the same device, so some users are in /a, some in /b, ..., but no one decided to put in /a/tmp, /b/tmp, ... directories. You can still do the mv trick by making the newversion file in the same directory as the old file, but if the system (or the updating program) crashes in the middle of the update you have this ugly garbage file left over. UNIX users must always put exactly what they want in the file the first time :-) Paul Scherf, Tektronix, Wilsonville, Oregon, USA paulsc@tekecs.UUCP
idallen@watmath.UUCP (03/22/84)
If a program needs a file under /usr, building it in /usr/tmp and
"mv"ing it is easier than building it in /tmp and having to "cp" it.
--
-IAN! (Ian! D. Allen) University of Waterloomcferrin@inuxc.UUCP (P McFerrin) (04/06/84)
On our UNIX 5.0 systems, /tmp and /usr/tmp are cleaned out during reboot. Since /tmp is root, space is very tight but /usr/tmp usually has lots of room (relatively speaking). We encourage users to use /usr/tmp for temporary files. However, specific scripts and programs that we need to utilize while in single-user use /tmp since /usr is usually not mounted. This is why such guys as ed(1), cc(1),..... use /tmp. If they used /usr/tmp, you would be restricted in what you can do in single-user. Since we have gone to RP07's for our 780's, space on / is not tight anymore. But, in general, we still use /usr/tmp as a practice.