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

Brian Wheeler bdwheele at indiana.edu
Wed Jun 20 17:38:27 UTC 2012

So, how does this scenario work?

* The machine has 4G of RAM,
* > 50% RAM is being used by actual software (firefox, eclipse, mail 
client, etc), so the other < 50% is pagecache
* The machine has 4G of swap, none of which is active.

So then a user drops a 8.5G DVD image into /tmp.

On a traditional /tmp-on-disk if it filled up then you'd get an ENOSPC 
and user things can't write to disk, but the OS will be fine since 5% is 
reserved for root.

With tmpfs the pagecache will fill up and start to overflow to 
swap...until swap fills up. What happens then?  As I understand it, the 
program gets ENOSPC and there is NO free RAM:  pagecache is full of that 
dvd data.  swap is full of that dvd data.  The rest of the RAM is 
program data that has nowhere to page out to.  The system may not have 
crashed, but it is fubar:  welcome to OOM killer territory

The answers of "don't do that, use /var/tmp" or "allocate more swap" are 
crap.  The software isn't broken if it writes to /tmp, regardless of how 
many bugzilla entries get filed.  Allocating more swap is a cop out 
because you've only pushed the problem to some file size that is larger, 
and you've tied up disk for a worst case scenario that may never come.

This introduces behavior that is highly dependent not only on the memory 
configuration of the machine, but the usage at the time the allocation 
happened, making this impossible to troubleshoot.

What are the benefits of this change again?  Clearing /tmp at shutdown 
is interesting, but can be accomplished in other ways (although not as 
cleanly), and I have yet to see any hard numbers on I/O even though I 
have asked repeatedly.


On 06/20/2012 01:18 PM, Gregory Maxwell wrote:
> On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>> i bet now someone is coming up wth "he must not dump a 100 Gb file to /tmp"
>> this is the wrong perspective
>> the right one is "the system must not crash if someone does"
> Good thing it doesn't.

More information about the devel mailing list