Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow <goswin-v-b@web.de>]

Henrique de Moraes Holschuh <hmh@debian.org> writes:

> On Fri, 25 May 2012, Thomas Goirand wrote:
>> for small files, and in that case, it's faster. In reality, it's
>> not that much faster, thanks to Linux caching of the filesystem,
>
> Under heavy filesystem IO load, yes it is.  By several orders of magnitude.

Even without load it is much faster because fsync() becomes a NOP. Disk
based filesystems add sequenze points where you have to wait for the
disk to catch up before continuing while tmpfs does not.

It also saves on wear of the disk if the files are small and short
lived, like temp files for gcc. No point writing the file to disk if it
gets deleted 10s later.

>> the point. Maybe we should add a /small-files-on-tmpfs (choose
>> a better name, of course...) folder so that apps know what to do,
>> that'd be a lot more graceful than just switching to whole /tmp
>> to tmpfs without any app knowing about it.
>
> Nice idea, but it would be worthless.
>
> In fact it is the other way.  We have /var/tmp for the large file since
> about forever, and important platforms that have /tmp in memory since the
> early 2000's (Solaris)....
>
> And that STILL wasn't enough for people to not screw it up and dump large
> files in /tmp.

There is also no problem with having large files in tmpfs. Only
requirement is that you make tmpfs large enough and add enough ram
and/or swap to cope with it.

All the complaints about /tmp as tmpfs come down to one simple issue:
The size of the tmpfs isn't chosen well. It would be more constructive
to find a better heuristic for the size there.

MfG
        Goswin