At 12:27 AM 4/11/96 -0700, John M Vinopal wrote:
>>Hmmm, I'd be pretty upset if I was in the middle of something at some odd
>>hour, like high noon or 4 in the morning, and /tmp went away.
>
>obviously you only remove things on order of a few days old.

"A few days old"? Please define. Be careful, because:
1) If you make the interval too large you defeat the purpose.
2) You make the interval too small, and you will nuke somebody, someday.
   This could happen, for example, if somebody was running a simulation
   of something that took "a few days" in /tmp, because there was nowhere
   else to run it. 

Long simulations come up because I have had to put up with my fav computer
lab on campus (NCSU) being "full" because 10 machines are in use by one
dude running a *long* simulation. We get 8mb quotas, and we get the use
of /tmp. That's it (officially, see /var/mail comment below). So long
simulations *have* to run in /tmp. Besides, it would blow chunks to run
them across AFS, and be expensive to give every student the server space
to do whatever. 

Our /tmp gets cleaned on user logout. This way we are almost positive that
the user didn't want the files left in there. 

>
>All usage is problematic if:
>
>/var should never fill
>/var/tmp/vi.recover should seldom be nuked

yup.

>/var/mail is HIGHLY important

Uh, *usually*. What if you have 30,000 user accounts, and several thousand
machines to keep track of? You go with POP. Then /var/mail has no importance
at all (where does SunOS 5.4 sendmail keep mail that is queued?).

The only reason I mentioned it is I was picking at our Computing Center,
who left /var/mail wide open on our machines. We don't use it, ever. 
It's just space on client machines that we found and started using as 
spare space, keeping in mind that one day we might loose the stuff stashed.

I've heard people mention rewriting sendmail some other way. Would an 
implementation of sendmail similar to POP be worth tossing around? It would
run on an account that had permissions to just the spool, and users could
run a POP-like client for it? This would eliminate the /var/mail hole
for the most part (I could still email myself a 100mb file if I wanted to).
>
>Solution is to throw more disk space at the problem.  Or link /var/tmp to
>/tmp and accept that you'll lose vi.recover over reboots.  The i386 limit 
>of 5 devices per disk doesn't help either.
>

How much space is enough?
--
XCOMM Kevin P. Neal, Sophomore, Comp. Sci. \    kpneal@interpath.com
XCOMM  Frue, Secret Agent of Smerp (shh!)   \   kpneal@eos.ncsu.edu
XCOMM Visit the House of RetroComputing at  /      Perm. Email:
XCOMM  http://www4.ncsu.edu/~kpneal/www/   /    kevinneal@bix.com