[ubuntu-cloud] RFC on Cloud Images: Make /tmp a tmpfs

[Clint Byrum]

Excerpts from Dustin Kirkland's message of 2016-01-16 04:25:58 -0800:
> On Fri, Jan 15, 2016 at 2:25 AM, Seth Arnold <seth.arnold at canonical.com> wrote:
> > On Thu, Jan 14, 2016 at 12:27:58PM +0200, Dustin Kirkland wrote:
> >> Moreover, just 'sudo apt-get install swapspace' and watch as swapfiles
> >> are created/deleted as needed.  If your root disk is lvm-encrypted,
> >> then obviously such swap files are encrypted, too.
> >
> > I've been severely skeptical of the swapspace package:
> >
> > - Swap is used when the system is already under pressure; a few hundred
> >   megs is great and probably for the best but if the system is actively
> >   pushing beyond that then it's being pushed too hard.
> >
> > - If the swap space is going to be allocated on the fly, that means the
> >   disk blocks have to zeroed on the fly, when the system is under
> >   pressure, rather than at some leisurely time beforehand.
> >
> > - If the swap space is allocated on a filesystem, it's probably being
> >   allocated from a fragmented filesystem that's 90% full rather than a
> >   nice contiguous block of space as it would with a swap partition.
> >
> > - Accessing further into a file may involve loading multiple indirect
> >   blocks from disk into unswappable kernel memory. A swap partition does
> >   not require indirection blocks.
> >
> > - If the swap space allocated from a filesystem pushes the filesystem to
> >   95% full (or whatever is left after accounting for reserved blocks),
> >   programs will error and almost nothing handles "disk full" errors
> >   gracefully. Swap partitions do not cause surprise gigabyte losses in
> >   free space.
> >
> > - Swap files can't be allocated from btrfs filesystems and probably
> >   shouldn't be allocated from zfs filesystems either. (Swap on zvols,
> >   maybe.)
> >
> > Perhaps the swapspace package uses some tasteful tunables to mitigate
> > against my concerns but the end result is that it contributes extra load,
> > extra IO pressure, and extra uncertainty at a time when the system is
> > already experiencing too much load, too much IO pressure, and too much
> > uncertainty.
> >
> > The risks and downsides of swapspace feel like a lot compared to the
> > slight hassle of having the installer make a swap partition.
> 
> I count 4 "if's", 3 "probably's", 2 "should/would's", and 1 "maybe" in
> that reply :-)
> 
> Perhaps try it out?
> 
> I've been running it and /tmp on tmpfs for several years (since before
> ~precise) on my desktop on an encrypted LVM partition.  My machine has
> a lot of memory (16GB), though I do push it hard), and have never
> noticed a swapspace-related problem.  I've also used this combination
> on hundreds of servers, and several production systems.
> 

The 'if' and 'probably' are missing in your anecdotal evidence though.
If you use the servers the way you have, it will probably work fine.
Also we're talking about cloud instances, not "servers", which have
quite different use and performance profiles.

I'd like to see even some rudimentary experiments done with realistic
workloads before saying this is a better idea than leaving things as
they are. We've all speculated and provided anecdotal evidence enough to
warrant such an investigation for those who speculate it will be a
worthwhile change.