FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-25-2012, 10:40 AM
Chow Loong Jin
 
Default Moving /tmp to tmpfs is fine

On 25/05/2012 18:20, Salvo Tomaselli wrote:
> 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

That doesn't seem to happen with file-roller. Perhaps you need to file a bug
with your graphical archiver program.

--
Kind regards,
Loong Jin
 
Old 05-25-2012, 11:58 AM
Thorsten Glaser
 
Default Moving /tmp to tmpfs is fine

Chow Loong Jin dixit:

>On 25/05/2012 18:20, Salvo Tomaselli wrote:
>> 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
>
>That doesn't seem to happen with file-roller. Perhaps you need to file a bug

Hm. mc does put things into /tmp as does debdiff, but the latter
at least honours TMPDIR (and --no-unpack-tarballs).

But in the very most cases, I *do* want them to be extracted in
/tmp as they “usually” fit. So I’d rather have a heuristic put
into the file manager whether to set TMPDIR before calling the
extraction utility (or which tmpdir to use if it designates the
extraction place by itself). mc maintainers, are you listening?

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.BSM.4.64L.1205251155530.7426@herc.mirbsd.org" >http://lists.debian.org/Pine.BSM.4.64L.1205251155530.7426@herc.mirbsd.org
 
Old 05-25-2012, 12:25 PM
Serge
 
Default Moving /tmp to tmpfs is fine

2012/5/25 Neil Williams wrote:

> You cannot expect to mix those two worlds and for things to "just
> work".

Easy. Let's leave /tmp on a real disk and both world will "just work".

> If program A is too resource-hungry, find (or write) program B.

Or fix the program A, right? And here we go... By default the program
Debian is too memory-hungry (with large tmpfs) or breaking apps (with
small tmpfs). Let's fix that?

> 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.

Every system becomes "Low memory" with these defaults. Assuming you've
set your tmpfs size to 20% you need 2.5GB memory just to "temporarily"
unpack kernel sources and check for some files.

Or it's supposed to be unpacked not in /tmp? And other programs should
not be using /tmp to write large files? Then what *real* programs should
use /tmp now? Is it useless for popular programs?

> That does NOT mean that Debian should change the default just to suit
> low memory devices. [...] we just have to be careful what applications
> we use.

So instead of fixing the defaults you suggest everybody to drop the
programs they use (mc, firefox, mysql)?

--
Serge


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOVenEpEOyAyOVKszAJvdJg2Urf-LqvNzC1=kvVrs04KCnEccA@mail.gmail.com">http://lists.debian.org/CAOVenEpEOyAyOVKszAJvdJg2Urf-LqvNzC1=kvVrs04KCnEccA@mail.gmail.com
 
Old 05-25-2012, 03:15 PM
Neil Williams
 
Default Moving /tmp to tmpfs is fine

On Fri, 25 May 2012 15:25:58 +0300
Serge <sergemdev@gmail.com> wrote:

> 2012/5/25 Neil Williams wrote:
>
> > You cannot expect to mix those two worlds and for things to "just
> > work".
>
> Easy. Let's leave /tmp on a real disk and both world will "just work".

Do you not use swap?

> > If program A is too resource-hungry, find (or write) program B.
>
> Or fix the program A, right? And here we go... By default the program
> Debian is too memory-hungry (with large tmpfs) or breaking apps (with
> small tmpfs). Let's fix that?

Write program C which does only the bits of what program A does but
does it by using a lot less resources (generally there's no point
differentiating between machines with low RAM and low storage space).

e.g. netsurf in place of iceweasel. GPE instead of XFCE/Gnome.

Yes you lose functionality but functionality takes up resources, so
something has to give.

> > 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.
>
> Every system becomes "Low memory" with these defaults.

Huh? Not true. The vast majority of systems have large amounts of swap,
so tmpfs never runs out until the swap space is full - it just gets
very, very much slower.

> Assuming you've
> set your tmpfs size to 20% you need 2.5GB memory just to "temporarily"
> unpack kernel sources and check for some files.

And? The machines I use to unpack and repack kernel packages handle
that quite nicely.

> > That does NOT mean that Debian should change the default just to suit
> > low memory devices. [...] we just have to be careful what applications
> > we use.
>
> 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.

I write packages for both types of machines - I use powerful servers
with lots of RAM and lots and lots of disc space for the repetitive
tasks of creating smaller packages which can be more easily handled by
low resource devices which have no swap, less than 1Gb of SSD and
only 512Mb RAM. Then I write lots of new code on nice shiny
workstations with lots of RAM and lots of disc space and deploy
those packages on the units which gives a full user interface
environment using (currently) ~21% of the available 512MB of RAM.

rootfs 1020M 757M 264M 75% /
tmpfs 62M 0 62M 0% /lib/init/rw

No problem with tmpfs being in RAM, it's all about being rational in
the selection of packages.

That way, the units can run on minimal power for days when the original
desktop would drain the UPS in 10 minutes.

Different hardware -> different software selection.

When a package requires too many resources for a particular device, you
simply choose another package, write another package or expand the
hardware. As the proverb goes, you can't fit a gallon into a pint pot.

http://www.emdebian.org/

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 05-25-2012, 05:14 PM
Serge
 
Default Moving /tmp to tmpfs is fine

2012/5/25 Neil Williams wrote:

> Do you not use swap?

I use it for suspend-to-disk.

> Yes you lose functionality but functionality takes up resources, so
> something has to give.

Which functionality will I lose by placing /tmp on the real disk?

> The vast majority of systems have large amounts of swap, so tmpfs never
> runs out until the swap space is full - it just gets very, very much
> slower.

Right, system will become unusable and user will press Reset button far
before that.

>> Assuming you've set your tmpfs size to 20% you need 2.5GB memory just
>> to "temporarily" unpack kernel sources and check for some files.

> And? The machines I use to unpack and repack kernel packages handle that
> quite nicely.

Since we're talking about default settings, you assume default debian
system to have at least 2.5GB just to be able to unpack kernels?

> Different hardware -> different software selection.

I don't understand your point. I could understand it if we were choosing
among benefits that most users get from /tmp being on disk and /tmp being
on tmpfs. But there're NO benefits in having /tmp on tmpfs. It works (not
works better, just works somehow) only on systems with a lot of RAM. And
nobody still named any popular programs, that can definitely benefit from
that. While there're many programs that either break or may render system
unstable.

Yes, /tmp on tmpfs works in many cases. But /tmp on disk works always.
Why would we select the worst of these two options?

I don't understand, do you suggest to break some applications and make
system less stable for nothing? What's a good part?

--
Serge


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOVenEr24CyHFALpn5J0mnfqLk+S3ovHqL+=bMR6qr-rVH=9rg@mail.gmail.com">http://lists.debian.org/CAOVenEr24CyHFALpn5J0mnfqLk+S3ovHqL+=bMR6qr-rVH=9rg@mail.gmail.com
 
Old 05-25-2012, 08:26 PM
Iustin Pop
 
Default Moving /tmp to tmpfs is fine

On Fri, May 25, 2012 at 08:14:10PM +0300, Serge wrote:
> 2012/5/25 Neil Williams wrote:
> > Different hardware -> different software selection.
>
> I don't understand your point. I could understand it if we were choosing
> among benefits that most users get from /tmp being on disk and /tmp being
> on tmpfs. But there're NO benefits in having /tmp on tmpfs. It works (not
> works better, just works somehow) only on systems with a lot of RAM.

This is plain wrong. NO benefits for tmpfs? "just works somehow"?

Whatever other arguments you had, the statement above tells me you only
look at _your_ use case and dismiss all others, or that you don't
understand the different behaviours of fsync() (with enough memory, that
is) on tmpfs, HDDs and SSDs.

And no, "I really can't think of any popular application" is not a valid
discussion point.

iustin, happily using /tmp on tmpfs since many, many years ago, and
configuring it as such on all Debian machines he installs (of various
roles).


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120525202638.GA19276@teal.hq.k1024.org">http://lists.debian.org/20120525202638.GA19276@teal.hq.k1024.org
 
Old 05-26-2012, 05:59 PM
Wookey
 
Default 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/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120526175935.GE11469@stoneboat.aleph1.co.uk">htt p://lists.debian.org/20120526175935.GE11469@stoneboat.aleph1.co.uk
 
Old 05-26-2012, 06:52 PM
Mike Hommey
 
Default Moving /tmp to tmpfs is fine

On Sat, May 26, 2012 at 06:59:35PM +0100, Wookey wrote:
> 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.

Or, it should get clever and not unpack everything. There are plenty of
software that are able to read into archives without extracting from
them. There are even fuse filesystems to do that if it doesn't want to
do it itself. Using a temporary directory, be it on disk or in RAM, is
*always* going to be a limitation. As a matter of fact, i remember some
virtualization solution (vserver or lxc, i think) that gave me a 16MB /tmp
by default. It doesn't matter if it's on disk or in RAM at this point.
If mc is going to try to unpack a kernel archive in there, it's going to
blatantly fail. Yet, there's no excuse for it to not do better.

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120526185205.GA24077@glandium.org">http://lists.debian.org/20120526185205.GA24077@glandium.org
 
Old 05-26-2012, 07:13 PM
Salvo Tomaselli
 
Default Moving /tmp to tmpfs is fine

> Or, it should get clever and not unpack everything. There are plenty of
> software that are able to read into archives without extracting from
> them.
You can't do it for a .tar.gz or a .tar.bz and they are the most common kind
of archive.

--
Salvo Tomaselli


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201205262113.26922.tiposchi@tiscali.it">http://lists.debian.org/201205262113.26922.tiposchi@tiscali.it
 
Old 05-27-2012, 02:39 AM
Serge
 
Default Moving /tmp to tmpfs is fine

2012/5/25 Iustin Pop wrote:

> And no, "I really can't think of any popular application" is not a valid
> discussion point.

But there're already popular applications and usecases that break because
of that. It can render the system unstable because of heavy swap usage.
So there must be some strong point to still use it despite those problems.
There must be some very popular application, that do not break because
of that feature and even becomes better.

Otherwise, if this feature causes problems to some applications and no
benefits to others, what's the point in using it?

> This is plain wrong. NO benefits for tmpfs? "just works somehow"?

Ok, I must be missing some obvious benefit. Please, help me and name it.
But real one not theoretical. Some real (and popular, since we're talking
about defaults) application that becomes faster (or better in any other
way) because of /tmp being on tmpfs. All the tests showed tmpfs being no
better than ext3 so far.

> you only look at _your_ use case and dismiss all others, or that you
> don't understand the different behaviours of fsync() (with enough memory,
> that is) on tmpfs, HDDs and SSDs.

I don't dismiss them. But we talk about *defaults*. And I don't know
any real applications, heavily fsync()ing files in /tmp, that people are
expected to use by default. Can you name some?

> iustin, happily using /tmp on tmpfs since many, many years ago

Heh... A lot of people use it. I guess most of them have seen "/tmp", then
they were seing "tmpfs", and decided that "tmpfs is the fs for /tmp", it
seemed natural to them. They never really thought, whether it's good or
bad idea, or that there may be some better ideas. It was just natural to
use it.

And when I say, "hey, that's a bad idea", I hurt them (I'm sorry for that).
They start arguing that "it's not that bad as you say, look, not everything
is broken, many programs still work". They can't say why it's better than
using disk because they never though about that. It was just "natural"...

That's just my guess, of course.

--
Serge


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOVenEoM+NFEmjxs61XqekBBt0ui5_EPW0yL9T930rATVHeYq g@mail.gmail.com">http://lists.debian.org/CAOVenEoM+NFEmjxs61XqekBBt0ui5_EPW0yL9T930rATVHeYq g@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 06:34 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org