RFC on Cloud Images: Make /tmp a tmpfs

[Serge Hallyn]

Quoting Clint Byrum (clint at ubuntu.com):
> Excerpts from Ben Howard's message of 2016-01-13 04:26:13 -0800:
> > All,
> > 
> > On the Ubuntu Cloud Images, we have a request to make /tmp a tmpfs. The
> > rationale, from the bug:
> >  * Performance - much faster read/write access to data in /tmp
> >  * Security - sensitive data would be cleared from memory on boot,
> >    rather than written (leaked) to disk -- important for encryption
> >    scenarios
> > 
> > Since the Ubuntu Cloud Images are used by a wide number of users, I
> > wanted to gather feedback and gather consensus on whether or not we
> > should make this change.
> 
> The two arguments in the bug are:
> 
> a) It is more secure
> b) It is faster
> 
> (a) is only half-correct. _IF_ the system has 0 swap configured, then
> tmpfs will never be on disk. But if there is swap, then it will very
> likely end up on disk. The answer to this is LUKS, not tmpfs.
> 
> (b) is overly general. For some things, this is absolutely true. For
> others, the opposite is true. Some tmp usage will overrun the available
> RAM and end up using swap directly, which does not have all of the tuning
> of the VFS layer, and thus will perform in a much less predictable
> manner. Plus, some programs use temporary files specifically because
> they know they're about to do something that will be overly expensive
> to guarantee RAM speed on, like sorting a file of arbitrary size. The
> choice to make in-ram things slower is generally made when the system
> owner chooses how much swap to make available. So making those operations
> which the developer has chosen to allow to be spooled onto disk faster,
> isn't actually a big win. However, failing those operations because of
> a lack of space in /tmp is quite frustrating and could be very costly if
> they must be retried.
> 
> So, the current paradigm is actually the more conservative, more
> generally acceptable approach. Making /tmp a tmpfs is an optimization
> _for some use cases_, which I think should be fine, but doesn't seem
> worth taking a risk with all cloud image use cases.

I think your mariadb case in particular is a good rationale for leaving
it how it is.