/tmp on tmpfs

Chris Adams cmadams at hiwaay.net
Tue Apr 3 15:35:10 UTC 2012


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?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


More information about the devel mailing list