2012/5/31 Uoti Urpala wrote: >> you eat cache memory. Meaning, you store /tmp files in cache even when >> they're not used, so kernel cannot use that memory to store some useful >> files. This increases I/O and makes the system slower. > > The tmpfs files will be written to swap if they aren't accessed much and > the kernel wants to cache other files.
They won't. I tried reading/copying gigabytes of files, tar/untar archives... As long as there're enough memory they don't get swapped. >> I mean, why would people want that feature? The only case I can think of: >> people with notebooks having SSD-disks, who want to reduce number of disk >> writes. And they usually want to do that for the whole disk, not just >> /tmp. There're a lot of ways to do that (starting from tuning kernel > > The reason "normal" filesystems write data to disk relatively soon is > not that it would be good for performance, but to avoid losing data in a > crash. Or rather "to lose less data in a crash". But you are free to modify kernel settings and change the timeouts, that's what kernel settings are for. ;) > Even if you're willing to accept a somewhat higher risk of data > loss on such a notebook, you'd very rarely want to use settings > appropriate for /tmp where it's OK to lose any or all writes done since > the machine was booted up. Thus your "do that for the whole disk" > comparison is wrong. The comparison is not about how much data to lose, but about how to reduce writes amount. What's the point in mounting /tmp to tmpfs if it breaks 20% of the apps you usually need, but saves you 1% of disk writes? Why not do something better instead? > Also, nowadays normal filesystems are journaled; using a journal for > writes to /tmp damages the SSD for zero benefit. Yeah, that's a popular opinion. But how true is it? I mean, how much does the journal increases amount of writes? I don't know, never tested that. Can you tell how many writes are added by journal in your case? Is it 20%, or 10%, or 1% or maybe %0.1? Does it worth worrying? Of course I understand that it's user-specific, and a gentoo world rebuild produces different results from internet browsing. So I'm not asking about some general stats for an average user, just in your case how many writes are added by journal? Anyway, if you care about journal, you should care about the whole disk, since most writes are not related to /tmp. In real applications /tmp is mostly unused, while /home and /var produce most of the write attempts. So worrying *only* about /tmp is pointless. I'm not saying that there's nothing to worry about. It's up to you whether you want to worry about SSD writes or not. I'm saying that by mounting /tmp to tmpfs you solve nothing. Even worse, that may give you a false safety feeling. But if you care, debian already has everything you need, here are a few suggestions that can help you: Option 1: Normal: don't write some things ========================================= The idea is simple: you need to find most writing apps and configure them not to do that. To find such apps you can use tools: iostat iotop btrace ... You may also look at audit-related tools. Or you can write your own scripts using /proc/diskstats and /proc/PID/io. Next step depends on apps you use. For example, you may want to use private browsing in firefox. Or if you're heavily using vim you can disable its swap file (`set noswapfile` in .vimrc). If you notice that your (K)DE often writes to /var/tmp, you can mount /var/tmp to tmpfs. :) Of course you would probably want to increase dirty_*_centisecs timeouts to some larger values. In my case most writes were done by browser (so I disabled caching, symlinked history/cache to tmpfs) and syslog (disabled fsync). It takes some time to catch all the apps. You may want to write some script and leave it running in background and collecting stats of running processes, so you could monitor your writes from time to time. Option 2: Paranoid: only write things you need ============================================== Assuming that you have a normal non-SSD PC: 0. Split your SSD disk into two partitions "meta-root" and "other". The "meta-root" partition will contain your system, while all the files you want to save would be on "other" partition. 1. Create a debian livecd with all the software you need: http://live.debian.net/manual-3.x/html/live-manual.en.html#7 2. Unpack content of the livecd to "meta-root" partition. 3. Manually install boot-loader (i.e. grub or syslinux) to "meta-root" 4. Configure boot-loader to boot your livecd 5. Boot and use. :) Whenever you need to write something — write it to "other" partition. If you need some software that you forgot to put on a livecd, or if you want to upgrade — leave a note to yourself on "other" partition, later rebuild livecd and replace files on "meta-root" partition with a new build. This is harder to configure, but allows you to control every disk write happening in your system. Also this gives you a flexible "undo": if something goes wrong with new livecd build, put older build back. These options should really help you to reduce writes amount, and you can even measure how much they do. -- Hoping to help, Serge -- 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/CAOVenEqq472fA=twwuussmbmmjhzexycye4xpjmjpm23bgh...@mail.gmail.com