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

[Gregory Maxwell]

On Fri, Jun 1, 2012 at 12:32 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>> I'm sorry, I couldn't quite hear you— perhaps more all-caps would help? :-)
>>
>> The dogmatic 'swap is bad for performance' is justified only because
>> writing/reading a slow disk is bad for performance.
>
> and how does /tmp in RAm change this?
>
> it enforces swapping because temporary files are
> held completly in memory and if they are large
> enough and your workload needs active RAm you
> enforce swapping

They are not held 'completely' in memory. The kernel can choose where
to store them based on the current demands on the system.  It can
store them on disk (though more cheaply than other FSes because it
doesn't have to worry about it being recoverable across a reboot) or
in memory.

> if they are on disk under /tmp they are cached only
> as long page-cache or active RAM is not needed for
> the workload and the memory can be released instead
> WRITE it do disk with swapping

This is how tmpfs works too, except without tmpfs some write activity
is required because the metadata updates (and data for sufficiently
long lived tmp files) will be written to disk.   So what the normal
buffer cache does for reading tmpfs lets it also do for writing.


On Fri, Jun 1, 2012 at 12:28 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
> * it is a valid workload that a application creates a 10 GB tempfile
> * ok, you say: use /var/tmp
> * well, i say: my whole rootfs is only 4 GB and 2 Gb are used

If your rootfs wasn't big enough for your tmp workload you would have
had to have had a separate tmp partition. Either continue to use it—
or mount it as swap and set size= to allow you to use it in tmp.

It works great.

On Fri, Jun 1, 2012 at 4:14 PM, Chris Adams <cmadams at hiwaay.net> wrote:
> I keep seeing sort as the primary example: how often are people sorting
> multi-gigabyte files?

I do this sort of crazy stuff all the time.  But— if I were just a
random user and did that sort of stuff I'd run out of space on root in
the process.  I don't run out of space in tmp because I make my tmp
big enough... just like I'd have to do if I wasn't using tmpfs.  Weird
workload require considerations, the use of tmpfs changing the default
tmp size might  move the weirdness boundary line around some but it
doesn't make a fundamental change in that.

At the same time it'll also be a good opportunity to find and fix
software that is needlessly writing enormous outputs to /tmp (which
could have been problematic for all users, including doing things like
causing data loss when /tmp is on the same volume as /home and filling
it up causes your programs to save zero byte file).