/tmp on tmpfs

Steve Clark sclark at netwolves.com
Tue Apr 3 16:30:55 UTC 2012


On 04/03/2012 11:35 AM, Chris Adams wrote:
> Once upon a time, Brian Wheeler<bdwheele at 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 at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120403/d02666a0/attachment.html>


More information about the devel mailing list