Re: Moving /tmp to tmpfs makes it useful

[Serge <sergemdev@gmail.com>]

2012/6/1 Goswin von Brederlow wrote:

> All the complaints about /tmp as tmpfs come down to one simple issue:
> The size of the tmpfs isn't chosen well.

Mounting /tmp to tmpfs not just breaks a lot of apps and reduces system
stability, but it actually does nothing else. You get no benefits from
/tmp being on tmpfs.
That's the complaint: the change makes something bad and nothing good.

> Even without load it is much faster because fsync() becomes a NOP.

Yes, it is. So it's a good idea to use tmpfs for some apps, that
heavily use fsync() on files that fit in RAM. But... wait... no app
is heavily using fsync() on files in /tmp. So it's useless to put
/tmp on tmpfs.

> It also saves on wear of the disk if the files are small and short
> lived, like temp files for gcc.

I guess you talk about SSD-like disks. Then...
1. short-lived files remain in cache and don't hit the disk.
2. gcc does not use fsync, does it?
3. gcc with -pipe option does not use /tmp
4. if you manually build something, you can add -pipe option to CFLAGS
5. if you build a package, you can add it to global build options
6. this doesn't matter, since pretty much nobody builds apps on SSD disks
So this is not even a corner case. :)

>> - There's not enough space, so the system starts swapping,
>> including some apps.
>
> Which happens regardless wether tmp is tmpfs or a real filesystem.
> The more IO there is the more likely some app gets swapped out.

No. I checked that. If you have e.g. 50% of free ram then whatever
files you read/write other apps won't get swapped, zero swap usage.
But if you start writing large files to tmpfs you get swapping.

> With tmps that instantly frees up all the memory and swap used by the
> file. With a real FS the file data remains in the dirty cache until such
> a time as the disk has cought up with writing it all and then it is
> thrown away. So potentially memory is freed up much later.

Actually cache also frees all the memory instantly on delete, but may
delay writing to disk. So only a few kilobytes of metadata are not freed.

>> Yes because writing that on disk will only block the thread performing the
>> write, not every thread that tries to allocate memory.
>
> Wrong.
Not that much.
> The thread doing the write will just write to cache and not block
> at all. That is until you run out of cache.
Until you run out of dirty_ratio, which is usually less than entire cache. :)

> No, tmpfs will be swapped out if you don't use a file for a while but
> something else uses memory, including IO caching.

It won't, I tried. I put a few hundreds MB on tmpfs and started reading
and copying gigabytes of files, tar/untar archives. I was still getting
no swap usage. As long as there's enough RAM they don't get swapped.

>> I'm asking for *popular* apps, that create files in /tmp, *never put
>> large files* there, and become *noticeably* faster with /tmp on tmpfs?
>
> gcc, ocamlopt, mc, lintian

Which of them becomes faster with /tmp on tmpfs? Can you suggest a use
case, that I can test with /tmp on disk and on tmpfs myself and see them
becoming faster?

-- 
  Serge