"/tmp" as tmpfs

Latest response

I know, judging by several threads I read on the Fedora mailing lists, this question likely invokes religion, but, since I'm in the process of helping our build team come up with standards for our soon to go to production RHEL 6 deployments, I'm feel compelled to ask, any way.

Prior to my current job, much of my UNIX work was done on Solaris based systems. As such, I was used to the /tmp mountpoint being a tmpfs filesystem rather than a "real" filesystem. Prior to the forthcoming RHEL 6 deployment, my current employer's use of RHEL was complimentary to Solaris - it's use was a beneficial side-effect of trying to push everything onto ESX and Oracle's bone-headed decision to effectively discontinue Solaris x86.

The RHEL 5-based standard build that was put together by prior engineers used /tmp as a "real" filesystem (ext3 on an appropriately sized LVM volume). I know that Linux has had the capability to support /tmp on tmpfs for quite some time. I know that some distros have even flirted with making that their standard (Fedora 18 being one of them, judging by the gnashing of teeth on one of the relevant discussion groups). So, what I'm looking for are two things:

  1. Why would(n't) I want our RHEL 6 builds to switch to the more Solaris-y /tmp on tmpfs - especially in ESX-hosted environments where disk-contention is likely to be of greater concern than memory-shortage
  2. How would I convert my KickStarts to set up /tmp as tmpfs rather than as a real filesystem? Can it be done in the main sequence-block of the KickStart configuration or would I need to do it as a %post operation (and any gotchas/ordering-issues in doing so)?


Despite the large amount of internet drama this has generated, I don't think there is inherently anything "good" or "bad" about using /tmp as tmpfs. Like any engineering change there are advantages and disadvantages. You just need to educate yourself about the behaviour you're going to see, decide to implement a change (or not) based on this education, ensure your applications are aware of this, and ensure your users are aware of this.

The biggest potential for problems I can see is that by default a tmpfs can consume up of 50% of system ram. You'll see this as "cache" usage in the "free" command, and if this fills to the point where it causes memory pressure, the system will start swapping. If you're putting 50Gb of data into /tmp on a system which has 32Gb RAM, then tmpfs is not the right tool for the job.

If your users/applications are expecting to write to /tmp and have that data there beyond a very short period of time, then they should be writing to /var/tmp instead. You'll then need to make sure you're cleaning out garbage in /var/tmp so you don't fill up that filesystem. You may wish to separate /var/tmp onto a separate filesystem, much like people have done with /tmp on a separate filesystem in the past. Basically move all your old /tmp practices to /var/tmp.

Coming from a Solaris background, use of "size=" to control that behavior is fairly second-nature. Ultimately, we'd probably opt to set the "size=" parameter to whatever size that tmpVol would previously have been built as - possibly even growing swapVol by the amount of the eliminated tmpVol (if it's not allocated to varVol or elsewhere).

Our /var, /var/log and /var/log/audit are all separate filesystems (as required by our security folks). So, things filling up are already fairly limited in their impact.

Users generally learn "don't use /tmp to store things you want to keep" fairly quickly. Given our environment, most of the (very few) interactive users are coming from Solaris, any way, and already expect the ephemeral behavior, any way.

Biggest problems I see are programs that expect /tmp to be more persistent. Because it's been the default on Solaris for at least a decade, programs ported to Solaris tend to be written with an ephemeral /tmp in mind. However, I know that some Linux programs aren't written that way.

In looking around at various tmpfs and kickstart discussions, haven't really seen anyone addressing setting up /tmp as tmpfs at provisioning time, however. 

[double-post deleted]