Serge <sergem...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txyqcgp8.fsf@frosties.localnet