On Sun, May 27, 2012 at 05:39:21AM +0300, Serge wrote:
> 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.

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

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

There are benefits, but your broken benchmarks don't show 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.

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

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

Which people? You can't overgeneralise.

I agree that the default sizes of tmpfs are likely wrong. But that
doesn't mean, as you claim, that tmpfs itself is wrong.

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

I appreciate this attack. It helps your point very much to paint people
who argue for tmpfs as clueless people.

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

Serge, I very much appreciate the fact that you're trying to make a
better experience for Debian users.

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

Honestly, other people in this thread have made the point against tmpfs
much better than you; I would suggest you tone down a bit your position,
and stop assuming ignorance on other's people part.

I will stop replying to this thread, because I don't have much to add;
there are pros and cons to both solutions, but I personally I'm still
surprised that people don't see the advantage of tmpfs for not
underpowered memory cases.

regards,
iustin


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

On Sun, 27 May 2012, Iustin Pop <iustin@debian.org> wrote:
> There's a difference between "tmpfs is bad" and "the defaults for tmpfs
> are bad".

The new defaults don't seem good when they are suddenly applied on upgrade.

My workstation unexpectedly went from having 2G of free space on the root
filesystem for /tmp to 600M of tmpfs. 600M is almost filled by two TED talks
so with my habits of downloading multiple video files that was never going to
work.

I think it would be a great feature to have the Debian installer give an
option of a tmpfs for /tmp. I think it would be quite OK to have it default
to tmpfs on /tmp but give the user the option of doing otherwise. But having
it just default to tmpfs and change existing systems on upgrade doesn't seem
that good.

This discussion has demonstrated that there are more than a few good reasons
to support both using tmpfs and not using tmpfs for /tmp. But I can't think
of any good reason for changing a working system, all of my systems running
Squeeze which should have a tmpfs on /tmp (IMHO - and I'm really the one who
knows) already have it. There is no need for a change when I upgrade.

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. But it
would still be good to not be surprised.

For installing new systems I don't think it matters much what the default is,
whatever is chosen will be good for some, bad for others, and probably not
matter to most people. But making it easy to change is a good thing.

--
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: 201205272338.19181.russell@coker.com.au">http://lists.debian.org/201205272338.19181.russell@coker.com.au

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?

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


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

On 05/27/2012 01:59 AM, Wookey wrote:
> 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.
>
Oh, that's right! I forgot about this one. I had the issue with
openoffice once, and my 1GB /tmp partition wasn't enough. It
filled more than 2GB of crap, in fact, and if this was on a tmpfs,
then it wouldn't have worked at all (eg: I wouldn't have had enough
RAM at the time).

It took me a long time to understand what was going on. If it was
someone else, like my mother or my wife (yes, they do use Debian ),
of course, they would never understand it.

Thanks for reminding me this one which we have to add to the big
list of heavy users of big-files in /tmp.

Thomas


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

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

then /tmp using tmpfs *will* lead to issues that many wont understand.

Thomas


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

On Sun, 2012-05-27 at 22:43 +0800, Thomas Goirand 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
> - ...
>
> then /tmp using tmpfs *will* lead to issues that many wont understand.

As will /tmp on a small root partition.
As will a small dedicated /tmp partition.

Creating arbitrarily large temporary files outside the user's home
directory is generally going to be unreliable. A shared /tmp also
results in various security problems (mostly mitigated by link
restrictions) and privacy problems (I can see the names of the files
your browser downloaded).

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

Ben.

--
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates

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.

Thomas


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

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?

Cheers,

Thomas


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

Wookey dixit:

>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

Yes. What I was trying to say was: set TMPDIR for many operations,
but file managers, such as mc, should be patched to apply heuristics
to determine whether to use /tmp or /var/tmp.

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

I think there is, but may be confusing with BSD, from which I know
for sure /tmp is cleaned at reboot and, daily, files older than
seven days. (Note that we see another benefit of tmpfs for /tmp
and for *most* files here: when mc segfaults again, its tempfiles
will not linger around long when in /tmp on tmpfs…)

>Perhaps mc should get clever and change TMPDIR itself on the fly for
>large files, but I don't know how practical that is.

Yes!

>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. (It could
for example do that only for the first few pages, doing others as the
timeline progresses.)

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

bye,
//mirabilos
--
13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
guy. But he's always right! In every fsckin' situation, he's right. Even
with his deeply perverted taste in software and borked ambition towards
broken OSes - in the end, he's damn right about it ! […] works in mksh


--
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.1205271749020.24443@herc.mirbsd.org ">http://lists.debian.org/Pine.BSM.4.64L.1205271749020.24443@herc.mirbsd.org

Thorsten Glaser wrote:

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

If you want to reach package maintainer, you have to mail
them specifically. They don't have to be subscribed to debian-devel.


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