Re: Moving /tmp to tmpfs makes it useful
Serge dixit:
>cases. Can you name some popular real-world program that write
>only small files and become noticeably faster when /tmp is on tmpfs?
Most shell scripts using << (here documents). mc, out of all things,
as long as the temporary files (e.g. of a tarball) fit inside it.
And countless others. The majority, in any case. What you want is
to optimise for a corner case.
>> Every tool either supports setting TMPDIR=/var/tmp before running
>> it or is buggy. Go fix these instead
>
>Do I understand you right? You suggest every tool that need large
>tmp files to use /var/tmp instead?
I do not suggest it. I say that every tool that doesn’t honour when
the user sets TMPDIR=/var/tmp is broken (but that’s nothing new, as
it has always been like that), and that the user should set that in
some corner cases like yours.
>Ok, then... what popular tools should use /tmp now?
/tmp (on tmpfs) should still be the default, as that’s the common
case, and one that can be optimised for well.
>/tmp on tmpfs won't help in that case. You do not reduce number of disk
>writes, you just move them to other directories. As you suggested, all
No. You reduce the number of disc writes quite a bit, as all current
filesystems use journalling and write more additional metadata than
paging would ever use. (And, from the other mail, the read accesses
could be fixed (for the slow HDD case) or don’t matter that much (for
the CF/SSD case).)
>the programs will still use files i.e. in /var/tmp. Or they'll write to
>swap if tmpfs is large enough. Or they'll just break, if it's small.
Ever heard of statfs?
>But you'll get the same number of SSD writes (or maybe even more,
>because of other applications being heavily swapped as well).
No. The common case wouldn’t swap them a lot, besides read-only
things (.text and .rodata, plus some bits) would not need to
be written anyway. So you’d still get less.
>Again, I'm not asking to drop this feature. I'm asking to have it disabled
>*by default* but supported by debian installer, so really smart people,
>that know what may be broken by it, but really need it, could enable it.
And I’m proving that it should be *enabled by default*, so that
really smart people like you, who need it disabled in corner
cases, can do that. And I’m suggesting that file managers that
extract archives apply some heuristics (size of the archive vs.
size and current usage of /tmp) to determine whether they should
use /tmp or /var/tmp.
>Most programs, using /tmp for temporary files, may write *large* files
No. The absolute majority writes *small* files there.
>there. So most programs fill tmpfs with large files. So tmpfs grows and
>swaps out (probably swapping out other applications as well).
You can always limit the size of your tmpfs? I think in Debian it
is already sized to a quite small (IMHO) portion of the main memory
by default.
>I really can't think of any popular application that write a lot of
>small-only files and can benefit from /tmp being on tmpfs. And I
$GUI_BROWSER_DU_JOUR with XTaran’s unburden-home-dir, for example.
bye,
//mirabilos
--
"Using Lynx is like wearing a really good pair of shades: cuts out
the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
-- Henry Nelson, March 1999
Reply to: