On 27/05/12 17:47, Thomas Goirand wrote:
> On 05/27/2012 11:25 PM, Ben Hutchings wrote:
>> As will /tmp on a small root partition.
>> As will a small dedicated /tmp partition.
>>
> Why taking just bad configurations as counter arguments?
> Do you know it is as well possible to have enough space
> in your /tmp?
>

I agree. Remember that we are not talking about if "tmpfs on /tmp" is
good or bad, but about if it is a good default.


Actually the default in squeeze is to have /tmp _as_ _large_ as your disk

* All files in one partition (recommended for new users) [1]


And since we are talking about defaults, I think that having "tmpfs on
/tmp" as default for Wheezy is a very bad idea.


If you know what tmpfs is, and you think it can improve things on your
machine: then just turn it on!. But please: don't make it a default,
since many users don't know what is tmpfs or a partition. And if they
are going to find all sort of problems because we did a bad choice with
this then is a problem for Debian and its users.


Regards!
--------

[1]
http://www.linuxbsdos.com/2011/02/15/debian-6-installation-and-disk-partitioning-guide/


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
Carlos Alberto Lopez Perez http://neutrino.es
Igalia - Free Software Engineering http://www.igalia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~

Ben Hutchings wrote:
> As will /tmp on a small root partition.
> As will a small dedicated /tmp partition.

The differences between these cases and forcing tmpfs by default is that
in the above cases, the person who installed the system chose those
partition sizes. They are therefore responsible for the breakage they
caused, and they can reason about this: "I told it to make / 200 mb, so
of course it can't write a CD iso there", and fix it.

However, the user who slaps a 2 terabyte disk in, and puts Debian on it,
has not made a choice that explains why Debian fails to burn a CD due
to having ignored all that disk space behind their back.

> We should be thinking about implementing per-user temporary directories
> and making sure that programs respect $TMPDIR.

Absolutely, but it's orthagonal to breaking previously sane defaults in
the size of /tmp.

--
see shy jo

On Sun, May 27, 2012 at 04:25:30PM +0100, Ben Hutchings wrote:
> We should be thinking about implementing per-user temporary directories
> and making sure that programs respect $TMPDIR. (On Linux it's also
> possible to give each user a different /tmp through mount namespaces.
> I'm not sure whether that's compatible with historical use of /tmp by
> the X window system.)

Yes! This is a good idea for other reasons, too, including some disc
encryption situations. Perhaps it's a candidate for a release goal for
wheezy+1? Some scoping work is probably required.


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

2012/5/27 Iustin Pop wrote:

> There's a difference between "tmpfs is bad" and "the defaults for tmpfs
> are bad".

First, I'm not saying that tmpfs is just bad. It's GOOD. For some cases.
I use it myself when I need to be sure that (having enough RAM) some of
my *large* files will never leave the cache and will *read* really fast even
when not used for days. It's not about "tmpfs is bad". It's about "/tmp on
tmpfs is bad". And if "/tmp on tmpfs is bad", it does mean that "defaults
for tmpfs are bad", doesn't it?

> There are benefits, but your broken benchmarks don't show it.

Possible. That's why in almost every email I'm asking for a better test,
better usecase, some popular applications, anything, proving it's good.
But still...

> Your tests are wrong, as Adam Borowski very nicely explained.

My "test" was `time tar xf ~/linux-3.4.tar.bz2`. It's not "wrong", it's
probably the most real test suggested so far. Aren't you using tar/bzip2?
It's a much better test than some artificial bash/perl-scripts that nobody
use in real-life. And we're still talking about real-life default settings,
I hope.

Those bash snippets I wrote were just to check about fsync(). It's stupid
to change defaults because some useless bash script works faster.
Imagine that I wrote an application that works faster on reiserfs than
on ext*fs. Will you change debian *default* root filesystem to reiserfs
because of my own application that nobody else uses?

The truth is that tmpfs IS FASTER in some cases. The problem is that
*nobody* can notice that on *real* applications. So in some artificial
world on another planet /tmp on tmpfs could be a good idea, but we're
in the real world on Earth, aren't we?

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

> Which people? You can't overgeneralise.

Ok, honestly, I don't know ANY popular applications, heavily fsync()ing
files in /tmp. Can you name some? Otherwise what's the reason to optimize
for fsync() if noone uses it for /tmp?

> But I don't appreciate the fact that, in your overzealous attitude, you:
> - come up with faulty benchmarks, which show that you misunderstand what
> the bottlenecks are
> - make assumptions that people are using tmpfs because they are ignorant
> - claim that people are using tmpfs only because they have overpowered
> hardware

My guess about people using tmpfs is based on the fact that during last
few days of this discussion and a few monthes of previous discussions
I've read through nobody had finally said why using /tmp on tmpfs is good.
Everybody are trying to say why it's "not that bad", but *nobody* explains
why it's good. This is the first thread where we're at least trying to do
that (first benchmarks appeared).

And, by the way, I see nothing bad in people being ignorant. I am ignorant
in some things. It's impossible to know everything in the world. That's
why I ask others to help me and find out why /tmp on tmpfs is good. Or,
if we won't find it, disable it by default.

> Honestly, other people in this thread have made the point against tmpfs
> much better than you

That's because I'm NOT trying to find why /tmp on tmpfs is bad. It's easy
and obvious. Instead I'm trying to find why it's a good default. Is it?
Why? Is it good just because it's "not that bad"?

> I will stop replying to this thread, because I don't have much to add;
> there are pros and cons to both solutions

Then, can you, please, mail me directly, and name the pros. I'm trying to
collect all the points. And I still miss yours. I understand you believe
it's not bad for you. Ok. But why /tmp on tmpfs is good for you?

--
Serge


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

On Sun, May 27, 2012 at 4:43 PM, Thomas Goirand <zigo@debian.org> wrote:
> On 05/27/2012 02:52 AM, Mike Hommey wrote:
>> 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.
> You may or may not be right. That's not the point. Things are what they
> are, and we have to deal with them. Unless you want to rewrite/patch:
> - Firefox
> - mc
> - mysql
> - {open,libre}office
gscan2pdf too, I use it to send my tax receipt and It crash during
scaning due to this issue (tmpfs full)....

>


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

Salvo Tomaselli wrote:

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

xz compression format supports dividing files into blocks that are seekable
http://www.tukaani.org/xz/format.html

tar format itself has limitations, here is some planning of new format
http://duplicity.nongnu.org/new_format.html


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

On Mon, 28 May 2012, Thomas Goirand <zigo@debian.org> wrote:
> On 05/27/2012 09:38 PM, Russell Coker wrote:
> > Sure it's easy for me to fix that when upgrading and when compared to all
> > the other things I have to do on an upgrade it's not much of a big deal.
>
> It's *not* easy, this involve init.d script foo ATM. See #674517.

As noted in that bug report you can just edit /etc/default/rcS to make it not
use a tmpfs for /tmp. That is easy to fix.

On Mon, 28 May 2012, Jon Dowland <jmtd@debian.org> wrote:
> On Sun, May 27, 2012 at 04:25:30PM +0100, Ben Hutchings wrote:
> > We should be thinking about implementing per-user temporary directories
> > and making sure that programs respect $TMPDIR. (On Linux it's also
> > possible to give each user a different /tmp through mount namespaces.
> > I'm not sure whether that's compatible with historical use of /tmp by
> > the X window system.)
>
> Yes! This is a good idea for other reasons, too, including some disc
> encryption situations. Perhaps it's a candidate for a release goal for
> wheezy+1? Some scoping work is probably required.

Using a bind mount to make /tmp/.X11-unix available to the logged in user
isn't going to be difficult. What is /tmp/.X0-lock used for?

As for making it a release goal for wheezy+1, it can't be enabled by default
because usually the users expect to be able to share files via /tmp.

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201205281040.51599.russell@coker.com.au">http://lists.debian.org/201205281040.51599.russell@coker.com.au

On Mon, 2012-05-28 at 10:40 +1000, Russell Coker wrote:
> On Mon, 28 May 2012, Thomas Goirand <zigo@debian.org> wrote:
> > On 05/27/2012 09:38 PM, Russell Coker wrote:
> > > Sure it's easy for me to fix that when upgrading and when compared to all
> > > the other things I have to do on an upgrade it's not much of a big deal.
> >
> > It's *not* easy, this involve init.d script foo ATM. See #674517.
>
> As noted in that bug report you can just edit /etc/default/rcS to make it not
> use a tmpfs for /tmp. That is easy to fix.
>
> On Mon, 28 May 2012, Jon Dowland <jmtd@debian.org> wrote:
> > On Sun, May 27, 2012 at 04:25:30PM +0100, Ben Hutchings wrote:
> > > We should be thinking about implementing per-user temporary directories
> > > and making sure that programs respect $TMPDIR. (On Linux it's also
> > > possible to give each user a different /tmp through mount namespaces.
> > > I'm not sure whether that's compatible with historical use of /tmp by
> > > the X window system.)
> >
> > Yes! This is a good idea for other reasons, too, including some disc
> > encryption situations. Perhaps it's a candidate for a release goal for
> > wheezy+1? Some scoping work is probably required.
>
> Using a bind mount to make /tmp/.X11-unix available to the logged in user
> isn't going to be difficult. What is /tmp/.X0-lock used for?
>
> As for making it a release goal for wheezy+1, it can't be enabled by default
> because usually the users expect to be able to share files via /tmp.

I don't recall that being common practice on any multi-user Unix-like
system I've used. (It's also not something a Windows user would expect,
as they already get per-user temporary directories.)

Ben.

--
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.

+++ Thorsten Glaser [2012-05-27 17:52 +0000]:
> Wookey dixit:
>
>
> >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.
>
> Ouch. (But nobody said Staroffice/Openoffice/Libreoffice/whatsitsname
> was light.) This sounds like another of these cases where the software
> would benefit from changes _independent_ of the tmpfs setting.

> >So I'm with serge that this can be a real-world problem. I'm
>
> I don’t disagree but still stand by that these are corner cases.

How can 'opening a big .ppt I was just sent', be a corner case? That's
the sort of thing 'normal people' do on a daily basis.

And if we have any pretence of Debian being useful outside the people
on this list we really should have defaults which mean it 'just
works' (if your disk isn't full already).

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: 20120528061122.GK11469@stoneboat.aleph1.co.uk">htt p://lists.debian.org/20120528061122.GK11469@stoneboat.aleph1.co.uk

+++ Henrique de Moraes Holschuh [2012-05-27 11:04 -0300]:
> On Sat, 26 May 2012, Salvo Tomaselli wrote:
> > > 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.
>
> Yes, you can. But it is slow (requires one full pass to get the file
> catalog, and another to decompress file data), so you would do it only when
> you expect it to be better than the alternative.
>
> Still, if mc will obey $TMPDIR, it is not at fault. Does it?

Yes, it does. (I just checked). It even behaves well if the dir
specified does not exist (complains, but starts anyway, gives errors
if you try to open archives with no tmpdir, starts using it as soon as
it appears).

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: 20120528061543.GL11469@stoneboat.aleph1.co.uk">htt p://lists.debian.org/20120528061543.GL11469@stoneboat.aleph1.co.uk