Moving /tmp to tmpfs is fine
 

On Fri, 25 May 2012 02:22:24 +0300
Serge <sergemdev@gmail.com> wrote:

> What's a temporary file? Really, why would applications temporarily store
> its data in a file? They do that to *free some memory*. Placing those files
> back to memory renders the whole process of writing the file useless.

Most of the time when I'm writing stuff to use /tmp (or $TMPDIR
wherever that is), I'm using it only because I want to unpack something
which is already a file into a temporary location which is fast and
easy to remove without permission problems or having to setup anything
in advance. RAM is ideal for that.

$TMPDIR is ideal when a program needs to download something (or often a
collection of somethings) and then needs to inspect them, checksum
them, analyse, process and report on stuff about them and then throw
them away and move on to the next collection of somethings. Now that
may include processing them to upload them to somewhere else but still
the local temporary copy needs to be cleaned up too.

$TMPDIR is also important for control sockets and other clever pipe
type stuff.

> If the files are small and can stay in memory why would application save it
> to file?

Because it started out as a file and the program just wants to use some
of the stuff inside the file?

> Moving /tmp to tmpfs is effectively the same as suggesting to delete /tmp,
> because there's no use for it as a temporary files storage any more.

Not true. Temporary file storage is exactly why I need /tmp and
temporary files don't get much more temporary than when they only exist
in RAM. Having tmpfs to make RAM look like a filesystem is ideal.

> FHS
> ===
> Filesystem Hierarchy Standard defines two directories for temporary files:
> /var/tmp — for files that should be preserved between reboots
> /tmp — for files that should not be preserved between reboots
> It's simple and clear.

Yes and it is just what my programs need - space for files which need
to be retrieved as files, processed as files but then blown away
trivially.

It means that the programs need to be run on devices with reasonable
amounts of RAM - I don't really care. The programs need to be run on
devices with a lot of disc space too, a fast processor and a fast
network connection. That's life.

I also write programs which have to work on tiny SSD drives, in minimal
amounts of RAM and no network at all.

You cannot expect to mix those two worlds and for things to "just
work". If program A is too resource-hungry, find (or write) program B.

> Since it's only reasonable to store large data sets in temporary files,
> standard sets no size limits for these files. So if application's author
> had actually read FHS he should expect these directories to handle
> large files.

Temporary files can be large files. Large files may only need to exist
for a few seconds, it doesn't matter. Match the program to the
resources available on that device and if one truly doesn't exist, write
it.

> Let's check the real world and see what applications actually use /tmp.
> When you copy files in `mc` they're copied over /tmp/mc-username (to
> handle some complex cases, like copying from inside iso-image to ssh).
> When you click on a file in Firefox and select "Open with", Firefox stores
> that file in /tmp. You cannot assume these files to be small. When you
> watch large videos, adobe flash stores downloaded part of it as something
> like /tmp/FlashXXG49VWF. Archive managers may unpack archives to /tmp.
> CD burners store iso-files there. Image processing software was already
> mentioned in this list.

It's beginning to sound like your particular machines need either more
RAM or to use a different temporary location which is on a permanent
location. Just add some rules to clean it all up at reboot.

That does NOT mean that Debian should change the default just to suit
low memory devices.

(Other stuff I write is for v.low memory devices which don't have
swap, /tmp is on tmpfs in RAM and we just have to be careful what
applications we use.)

> Suggestion
> ==========
> Do not mount /tmp as tmpfs by default. Instead...

No. The default is fine and sane but no default will ever satisfy every
possible device. Low memory devices have many many more problems than
just where /tmp is mounted.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Moving /tmp to tmpfs is fine
 

> It's beginning to sound like your particular machines need either more
> RAM or to use a different temporary location which is on a permanent
> location. Just add some rules to clean it all up at reboot.
Perhaps there are a couple of thousand users with the same use case, I don't
know if it is the case but should be investigated rather than discarded.

> That does NOT mean that Debian should change the default just to suit
> low memory devices.
So let's put minimum requirements unnecessarily high so a few people with
super expensive laptops can have a 0.3μs speedup? (And people with cheaper
hardware might never find out why the hell "linux" freezes if they click on a
large tar archive).

> No. The default is fine and sane but no default will ever satisfy every
> possible device. Low memory devices have many many more problems than
> just where /tmp is mounted.
But with tmpfs on disk, more devices would work by default (the ones with a
lot of memory and disk, and the ones without much memory but with disk space).


Bye

--
Salvo Tomaselli


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201205251119.15851.tiposchi@tiscali.it">http://lists.debian.org/201205251119.15851.tiposchi@tiscali.it

Moving /tmp to tmpfs is fine
 

Am 2012-05-25 11:19, schrieb Salvo Tomaselli:
It's beginning to sound like your particular machines need either
more

RAM or to use a different temporary location which is on a permanent
location. Just add some rules to clean it all up at reboot.
Perhaps there are a couple of thousand users with the same use case,
I don't
know if it is the case but should be investigated rather than
discarded.


That does NOT mean that Debian should change the default just to
suit

low memory devices.
So let's put minimum requirements unnecessarily high so a few people
with
super expensive laptops can have a 0.3μs speedup? (And people with
cheaper

hardware might never find out why the hell "linux" freezes if they
click on a
large tar archive).


Doing that on inferior hardware is just plain stupid. If you have
plenty of

disk space, just unpack the tar archive.

No. The default is fine and sane but no default will ever satisfy
every
possible device. Low memory devices have many many more problems
than

just where /tmp is mounted.
But with tmpfs on disk, more devices would work by default (the ones
with a

lot of memory and disk, and the ones without much memory but with
disk space).


And those with lots of RAM but not so much disk space (SD card or USB
driver or
even with no hard drive at all)? There's no solution that works for
everyone in
all situations. However, tmpfs at least works for many of them. If you
KNOW
that this default does not fit your use-case, why don't you simply
change the

configuration?

HS


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: d77602e05a6b6ce8cd0072a717bf8ed2@mail.hendrik-sattler.de">http://lists.debian.org/d77602e05a6b6ce8cd0072a717bf8ed2@mail.hendrik-sattler.de

Moving /tmp to tmpfs is fine
 

> Doing that on inferior hardware is just plain stupid. If you have
> plenty of
> disk space, just unpack the tar archive.
Double-click on a .tar causes it to be unpacked in /tmp/something.
I suppose a lot of not so skilled users do that instead of tar -xf

> And those with lots of RAM but not so much disk space (SD card or USB
> driver or
> even with no hard drive at all)?
Can you link me one such device? Nothing pops in my mind. And how widespread
they are?
Normal desktop/laptop configurations have at least 100 times more disk space
than ram.
For servers.. it depends on the taks they are supposed to do, but usually
servers have an administrator who is more or less aware of what he is doing.

> There's no solution that works for everyone in all situations.
True.
But experts can change the defaults more effectively than non experts.

> However, tmpfs at least works for many of them. If you KNOW
> that this default does not fit your use-case, why don't you simply
> change the configuration?
The point is that the desktop user is often clueless and doesn't know it. He
will just notice the problem and will not have a clue of how to solve it.

So I would suggest that defaulting to a more safe configuration would be
better, and of course those who want tmpfs can always change the default. But
those who don't even know about what /tmp is would not end up with something
that doesn't work so well on their hardware.

Bye

--
Salvo Tomaselli


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201205251220.11062.tiposchi@tiscali.it">http://lists.debian.org/201205251220.11062.tiposchi@tiscali.it