[HEADS-UP] Rawhide: /tmp is now on tmpfs

[Gregory Maxwell]

On Wed, Jun 20, 2012 at 1:25 PM, Jef Spaleta <jspaleta at gmail.com> wrote:
> As a sysadmin...for a multi-seat configuration in a home network
> environment...do I really need to anticipate maximum large file tmp
> usage in calculating my swap partition size for my multi-user family?
> 8 gigs of ram... so to be safe I want to set up a swap of what...100
> gigs to account for a potentially large /tmp of some maximum size?

This is an issue you have independent of tmpfs.  How big does / need
to be? (or if /tmp is on another volume due to the fragmentation mess
it creates, how big does that volume need to be).

> Does swap backed tmpfs as /tmp currently jeopardize my system's health
> by making swap backup for in-memory processes compete with tmp files?
> If my users clog up /tmp will that reach a point where the kernel's
> oom process killer decided to start killing off running processes
> instead of throwing crap out of /tmp?

Tmpfs volumes have a size set as a mount option. The default is half
the physical ram (not physical ram plus swap). You can change the size
with a remount. When its full, its full, like any other filesystem

If you set it high enough that you could fill swap and physical ram
with tmpfs plus your workload, then yes, I believe you'd then see the
OOM killer run. I've never had this happen because I've never set my
tmpfs size larger than the available swap I had— so any OOM event
always was due to applications using up too much core.

> What happens when I have 2 users who are both downloading dvd iso
> sized images into /tmp  as well as other things going on. Remind me...
> where does firefox by default cache in progress downloads for the
> "Open in" facility. Isn't it down in tmp?   Do I really want things
> like firefox downloads paging out ram into swap and causing an overall
> system slowdown?

Yes, Firefox saves to /tmp by default.

Use of tmpfs will not not increase your disk IO. Under that workload I
would expect your DVD data to end up in the swap volume, there is no
adverse performance from this. At least in my experience/measurements
writing out large data to tmpfs has performance equal to or better
than writing out to regular filesystems.

> Without more information about how gracefully /tmp spill over into
> swap is handled, I'm inclined to say this really looks problematic as
> a default.
> And that's not even getting into the more complex issues of virtual
> machine configurations which typically run under heavier ram
> constraints than disk constraints.

It really sounds to me that you're using a "ramdisk" as a mental model
for tmpfs. That isn't what tmpfs is.  Tmpfs is a filesystem backed by
the kernel's buffer cache, and it can use whatever resources it likes
to back it up.  In practice small short lived things are purely in
ram, while larger long lived data ends up on disk— but it does so at
the kernel's leisure and in a manner which minimizes writes and
latency critical operations.