Re: Moving /tmp to tmpfs is fine
I hesitate to prolong this thread further, but I do have a couple of
data points. (and couldn't let Neil's nonsense go).
+++ Neil Williams [2012-05-25 16:15 +0100]:
> > So instead of fixing the defaults you suggest everybody to drop the
> > programs they use (mc, firefox, mysql)? ;)
>
> On machines which don't have the resources for those programs, yes.
> There are alternatives out there - change to a less hungry program or
> expand the hardware.
The idea that there are machines without the resources for mc is
silly. It's a very low-resource console-based program.
But there is this issue of the way its vfs does temporay unpacking in
/tmp. That makes sense in the 'this is temporary, it should go away on
reboot' sense, but some big files will use up a lot of ram when /tmp
is tmpfs.
I don't know what the right thing to do about this is, but the 'set
TMPDIR' sugestion is useless IMHO. When I start mc I have no idea what
things will be unpacked under the VFS over the next days/weeks. I
don't want _everything_ to go in /var/tmp and not get cleaned up
automatically (is there cron job that does this for old files?)
Perhaps mc should get clever and change TMPDIR itself on the fly for
large files, but I don't know how practical that is.
I only have 2G in this machine and astonishing slowdown due to
thrashing is quite common after a few days work (generally firefoxes
fault). I do begrudge /tmp (and thus tmpfs) having more than a few MB
of ram.
hmm. I just checked some stats:
after looking inside a 45MB .deb files in mc:
tmpfs 382M 212K 382M 1% /tmp
so it's not unpacking it there any more even though
MC_TMPDIR=/tmp/mc-wookey perhaps this issue is fixed at least for this
app?
here's a case where a lot of space gets used in there: open a .ppt
(powerpoint) file in libreoffice. The conversion involves writing a
file in /tmp/<mktmpdir> for every page/image. To open an image-heavy
256Mb .ppt I have lying about here, generates 382MB of files in /tmp.
I tried to do this live when someone was having trouble with a
presentation - it took over 20mins to open this file due to thrashing
and I was unable to save the presenation from being something of a
disaster. /tmp being a tmpfs presumably contributed to that failure
(It just opened fine in about 2mins on the same machine with less
memory pressure). And of course I didn't set 'TMPDIR' beforehand a)
because all I did was double-click on the file in the filer, which ran
libreoffice impress and b) because I had no idea that it would general
hundreds of megs of files in /tmp. (I found out afterwards).
So I'm with serge that this can be a real-world problem. I'm
not claiming that the only solution is a real-disk /tmp, because I
agree with those who do see advantages in /tmp as tmpfs so long as
/tmp stays fairly small.
> No problem with tmpfs being in RAM, it's all about being rational in
> the selection of packages.
'firefox' is a perfectly rational choice of package on this laptop of
2G ram. mc is a rational choice on any machine.
You can't solve the issue of 'unpacking huge tarballs/debs/whatevers'
in /tmp' by telling people to use different packages. Something else
is needed. It is possible that that something else already exists, but
I must admit to now being a little confused about what actually
happens as this thread contains conflicting info.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: