Re: Moving /tmp to tmpfs makes it useful
Serge <sergemdev@gmail.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.
>>
>> 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. :)
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
blocking.
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.
MfG
Goswin
Reply to: