Re: Moving /tmp to tmpfs makes it useful
- To: firstname.lastname@example.org
- Subject: Re: Moving /tmp to tmpfs makes it useful
- From: Serge <email@example.com>
- Date: Tue, 5 Jun 2012 09:29:46 +0300
- Message-id: <CAOVenEpfRZMzZPpsux8fib9G0cE-GnOum-mDkZn2NzkYXFWBvw@mail.gmail.com>
- In-reply-to: <firstname.lastname@example.org>
- References: <CAOVenEo+CT6Ou_vHq8HvuCz1NdW0Ogq5UqxMZh-4Qkw4e01CsA@mail.gmail.com> <20120525003051.GA1497@jwilk.net> <email@example.com> <CAOVenEqx1VLBmn4eJdFJ29PUj5ebJp9DHrMea7gprF8+GZd5Fg@mail.gmail.com> <4FBF16A3.firstname.lastname@example.org> <20120525101420.GA6872@khazad-dum.debian.net> <Pine.BSM.4.64L.email@example.com> <CAOVenEp+mr3yNi=4obCG2qtztFjuAJ_SvcUS1Y-7iJ5mNhj9GA@mail.gmail.com> <20120525125607.GC16397@belkar.wrar.name> <CAOVenEqkgq7pUD1xeneRvFxwzRh3qXk_xD9eWeUz7nKjDT2Chg@mail.gmail.com> <Pine.BSM.4.64L.firstname.lastname@example.org> <CAOVenEqwGS5sEgV6vAmyOQ0NX7Ro+14tLN79WYk6u1KF0bCEemail@example.com> <firstname.lastname@example.org> <email@example.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.
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