RFC on Cloud Images: Make /tmp a tmpfs

[Dustin Kirkland]

On Thu, Jan 14, 2016 at 6:49 AM, Steve Langasek
<steve.langasek at ubuntu.com> wrote:
> On Wed, Jan 13, 2016 at 11:00:16PM +0100, Martin Pitt wrote:
>> Ben Howard [2016-01-13 14:26 +0200]:
>> > 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.
>
>> I really wish we would do this in general for new installs, at least
>> as the first thing after releasing 16.04 LTS. I also do this on my
>> boxes, not only for the reasons above [1], but also because it is much
>> more power efficient -- as I literally work in /tmp a lot of my time
>> the disk doesn't need to spin up often.
>
>> The main reason AFAIK why we didn't yet do that was the concern that
>> there is some broken software out there which potentially dumps really
>> large files into /tmp (yes firefox, I'm looking at YOU!). These would
>> need to be fixed to go to /var/tmp. This is a chicken-and-egg problem,
>> though: We won't find out what's broken until we actually enable it on
>> real-life installations. This problem applies to cloud image use cases
>> just as much as desktop or "classic" servers.
>
>> My gut feeling is that we should do it if there is ≥ 4 GB RAM, so that
>> /tmp as at least 2 GB of space (That should be a rather simple
>> installer/cloud-init decision?). We don't want to do this on small
>> embedded devices with 512 MB of RAM or so, but there is absolutely no
>> reason to not do it on beefy servers or laptops.
>
> As a data point, I used to have my /tmp on tmpfs while I still had a
> spinning disk, in order to address the power usage issues of disk flushing.
> I found it to be a least-bad option which led to serious degradation of
> desktop interactivity in the face of even moderate memory usage (at the
> time, with 4GB RAM), and not because of excessive /tmp usage.
>
> And as others in this thread have noted, this same problem can occur in
> cloud instances.

Definitely.  /tmp on tmpfs saves energy when you have a spinning HDD,
and extends the life of your SSD by reducing the number of NAND flash
writes!