Re: Moving /tmp to tmpfs makes it useful
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
Reply to: