On 04/03/2012 11:35 AM, Chris Adams wrote:
Once upon a time, Brian Wheeler <bdwheele@indiana.edu> said:
* The competition for space between things in /tmp and VM.  When someone 
abuses space in /tmp (on purpose or not) then the system is going to 
start swapping and performance is going to suffer and the common 
response for fixing it will end up being 'just reboot'.  That's just gross.
First, tmpfs can be swapped.  If you are swapping tmpfs files, how is
that any worse than having /tmp on a disk?  Also, if some user has taken
up lots of space in /tmp, you can LART the user and delete the files;
that's no different than a user filling up a partition by writing to
/tmp (no reboot necessary in either case).

I've been running with /tmp on tmpfs for several years, including on a
number of servers, and I've never had any unusual problem related to it.
I typically provision a little more swap on such systems, so that
there's some room for spill-over.

Also, on servers where there are users with shell access, I'll typically
limit the size of /tmp with an option in fstab (the default is RAM/2,
which can be larger than I'd like).  However, reading the feature page,
this would be harder to do, since somebody's irrational fear of
/etc/fstab is extending to /tmp.  I think that's a bad idea, especially
since the proposed feature creates yet another way to mount filesystems
(systemd-"auto", /etc/fstab, and now a service for /tmp).  Really?  Two
wasn't enough?

I have been doing this also but limiting how much space can be used in /etc/fstab
with the size= option. To do away with being able to control this seems dumb.


--
Stephen Clark
NetWolves
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark@netwolves.com
http://www.netwolves.com