[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tmp on tmpfs



tomas@tuxteam.de (12023-04-19):
> What I didn't like from the post is that it doesn't clearly
> state the downsides. Too much handwaving and repetition that
> "there are downsides" (well, duh), that "some applications
> rely on... " (what?). Then he goes on to explain alternatives.

“If I can't write gigabytes files, it's completely and utterly useless”
is what I managed to read.

I am not that surprised to find this level of argumentation in a text
that announces its unbalanced conclusion in the title. Like all those
“foobar considered harmful” essays: they usually blame a caricature of
the other side, they argue against the worst possible version of the
idea and thus miss the points of their proponents.

I have only a limited sympathy for the self-styled rational “community”,
but their principle of “steelmaning” the other side argument before
trying to reply is a good one.

> The upsides aren't that spectacular either. If you've enough
> RAM, file system caching is so good that tmpfs will only be
> marginally faster: The write path to the disk will be a bit
> clearer. There will be a bit less CPU usage if your /tmp would
> be otherwise on a LUKS partition (mine would).

Another minor difference that can be a minor upside or downside
depending on the use case: with a tmpfs, the files disappear when the
computer is turned off, with a real filesystem they disappear when it is
turned on.

(I do not know if Debian has provisions to format a /tmp partition with
an ephemeral encryption key on boot, like it has for the swap.)

Regards,

-- 
  Nicolas George


Reply to: