/tmp on tmpfs

[Brian Wheeler]

On 04/02/2012 07:44 PM, Dave Jones wrote:
> On Mon, Apr 02, 2012 at 06:34:59PM -0400, Przemek Klosowski wrote:
>   >  On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
>   >  >* #834 F18 Feature: /tmp on tmpfs -
>   >  >    http://fedoraproject.org/wiki/Features/tmp-on-tmpfs  (mitr, 17:40:06)
>   >  >    * AGREED: tmp-on-tmpfs is accepted (+5 -3)  (mitr, 18:12:52)
>   >
>   >  The wiki page says:
>   >    By implementing this we, by default, generate less IO on disks. This
>   >    increases SSD lifetime, saves a bit of power and makes things a bit
>   >    faster.
>   >
>   >  What about the memory pressure? with on-disk /tmp, the buffer cache
>   >  prevents excessive writing if there's memory to spare, but the
>   >  system still works when memory is used up. What happens with tmpfs?
>
> tmpfs contents are pageable, and will be swapped out if necessary.

I can't say that as a user (and sysadmin) I'm really thrilled with 
this.  /tmp doesn't go away on reboots now so this is a biggish change 
from my point of view.  There have been several times where I've dumped 
things in /tmp that I needed after a reboot.  I really don't care what 
the LSB recommends in this case:  this is a pretty big behavior change.  
The hand-wavy rule for "big files" going to /var/tmp and little things 
going to /tmp is also gross since its creating a distinction that really 
doesn't need to be there.

I've also dealt with sloppy users in the past that would write things to 
a tmpfs /tmp (on solaris) and not clean them up.  Yes, its a programming 
issue, but I can't always control my users so  instead of giving 
warnings that the disk was getting full the performance went to hell 
because it was swapping like crazy.

I've looked at the benefits page on the wiki and I'm not seeing any 
benefits to me.  It seems more like someone that needed this solution 
would want to opt in to rather than forcing others to opt out of it.

Is there a reason why a symlink from /tmp -> /var/tmp and leaving 
/var/tmp on a real disk isn't sufficient for whatever is trying to be 
solved here?