Re: Moving /tmp to tmpfs makes it useful
- To: Serge <firstname.lastname@example.org>
- Cc: email@example.com
- Subject: Re: Moving /tmp to tmpfs makes it useful
- From: Goswin von Brederlow <firstname.lastname@example.org>
- Date: Tue, 05 Jun 2012 10:21:07 +0200
- Message-id: <email@example.com>
- In-reply-to: <CAOVenEpfRZMzZPpsux8fib9G0cE-GnOum-mDkZn2NzkYXFWBvw@mail.gmail.com> (Serge's message of "Tue, 5 Jun 2012 09:29:46 +0300")
- References: <CAOVenEo+CT6Ou_vHq8HvuCz1NdW0Ogq5UqxMZh-4Qkw4e01CsA@mail.gmail.com> <20120525003051.GA1497@jwilk.net> <firstname.lastname@example.org> <CAOVenEqx1VLBmn4eJdFJ29PUj5ebJp9DHrMea7gprF8+GZd5Fg@mail.gmail.com> <4FBF16A3.email@example.com> <20120525101420.GA6872@khazad-dum.debian.net> <Pine.BSM.4.64L.firstname.lastname@example.org> <CAOVenEp+mr3yNi=4obCG2qtztFjuAJ_SvcUS1Y-7iJ5mNhj9GA@mail.gmail.com> <20120525125607.GC16397@belkar.wrar.name> <CAOVenEqkgq7pUD1xeneRvFxwzRh3qXk_xD9eWeUz7nKjDT2Chg@mail.gmail.com> <Pine.BSM.4.64L.email@example.com> <CAOVenEqwGS5sEgV6vAmyOQ0NX7Ro+14tLN79WYk6u1KF0bCEfirstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <CAOVenEpfRZMzZPpsux8fib9G0cE-GnOum-mDkZn2NzkYXFWBvw@mail.gmail.com>
Serge <email@example.com> writes:
> 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.
You keep claiming tmpfs compromises system stability. Can you show a
kernel oops of a crash caused by 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.
A short-livd file goes to cache, as dirty pages. dirty pages are then
written to disk in the background.
Are you claiming that filesystem do un-dirty pages when a file is
deleted before it was actually written to disk? Do they remove the pages
from the write queue when they are already picked up for write out?
> 2. gcc does not use fsync, does it?
As Mike says any fsync on the same filesystem generaly will force write
the files in /tmp too.
> 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
Not the default and you were talking about inexperienced users.
> 6. this doesn't matter, since pretty much nobody builds apps on SSD disks
> So this is not even a corner case. :)
I think more than "nobody" has an SSD disk nowadays and they will only
become more popular. At best ignoring SSDs is short sighted.
>>> 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. :)
Unfortunately that limit seems to simply not work AT ALL. Writing to a
slow filesystem like NFS or a USB stick just keeps writing and writing
and writing till there is no more ram. With the obvious result of stuff
Also shouldn't/couldn't tmpfs fall under the same ratio (or equivalent
setting). No more than dirty_ratio pages should be dirty in tmpfs and
then it could start swapping them out even without memory pressure?
>> 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.
Well, worked here. I know swap usage/behaviour widely varries between
kernel versions. I've seen kernels that didn't use swap even after a
week but also kernels that used swap after an hour all with the pretty
much the same usage pattern on my desktop.
>>> 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?
All of them. In mc use the feature to look into tar/rpm/deb files.
And try running apt-get upgrade in parallel for extra fsync()s.