Why not have a /tmp *partition* ? (Was:RE:10 pounds...)

[doelz at urz.unibas.ch]

In article <9008061712.AA12595 at aero4.larc.nasa.gov>, blbates at AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") writes:

>    The problem (or disadvantage) with making /tmp a partition is
> that it is wasted space.  If you are not compiling or editting
> something that space is wasted.  If you link /tmp to say /usr/tmp
> you use your disk space more efficiently.
> --

Sorry, folks, that I'm still discussing disk quota 8-( occasionally.
 
The way I am using /tmp is to offer those who seem to be disk hogs a spare 
part of resources. Once a customer syas 'I need so much disk and you 
can't provide it' - I give him the hint to use /tmp instead. Usually these 
folks drastically underestimate their needs and show up again later demanding 
even more. The /tmp partition sets the final limit here - Once a 
partition is full, no one can work on it any longer. CAVEAT ! Works
pretty well as long as you have the following line in 
/usr/spool/cron/crontabs/root: 
0 2 * * * 
  find /tmp -local -type f -mtime +2 -atime +2 -exec /bin/rm -f '{}' ';'
You can play with that and also remove links and directories. Thats what 
we do but we give them a little longer lifetime. We even have a line which 
removes core files ona obvious junk in hourly intervals. 

BTW, there are two more candidates which use /tmp *heavily* and should 
not be forgotten: 4DDN (the 'Decnet' product) is usually having a home 
directory in /usr. We changed that to /tmp because depending on your 
security concerns anyone could write on your community account whithout 
privs (coming across the decnet protocol).  On the other hand, byte swapping 
of files is needed. And because neither the SGI supports DEC remote procedure 
calls nor does the VAX support Unix remote procedure calls, I usually need a 
place where I put the 'wrongly', non-byte-swapped, wrong-formatted (binary) 
file to. There are still some caveats in using decnet but /tmp as a community 
scratch space is important. 

The other candidate is the uopt. Did you ever notice the *enormous* size 
of the files generated by the compiler/loader if you run with O3 ?
Even if O3 is kind of special in some code :-) , sometimes it works and 
speeds up things considerable. 

Reinhard