2012/5/25 Thorsten Glaser wrote:

Ok, we have guesses, let's do some TESTS...

>> Can you name some popular real-world program that write
>> only small files and become noticeably faster when /tmp is on tmpfs?

> Most shell scripts using << (here documents). mc, out of all things,
> as long as the temporary files (e.g. of a tarball) fit inside it.
> And countless others. The majority, in any case. What you want is
> to optimise for a corner case.

Do they become faster? My tests show they don't (see below).

I'm asking for *popular* apps, that create files in /tmp, *never put
large files* there, and become *noticeably* faster with /tmp on tmpfs?
And remember that there're popular apps that break because of that,
so to make sure it's still a good thing all 3 conditions should be met.
We're talking about defaults, not about corner cases after all...

> I say that every tool that doesn’t honour when the user sets
> TMPDIR=/var/tmp is broken (but that’s nothing new, as it has always
> been like that), and that the user should set that in some corner
> cases like yours.

Browsers, filemanagers, flash video, cd burners... Do you basically
suggest every debian user to think whether it's a corner case or not
and manually select TMPDIR *every time* they start browser?

> You reduce the number of disc writes quite a bit, as all current
> filesystems use journalling and write more additional metadata than
> paging would ever use.

I believe you're not talking about some small short-lived temporary files,
because they never actually get to disk, kernel filesystem cache is smart
enough for that (unless you've changed dirty_writeback_centisecs and
dirty_expire_centisecs to some low values).

So you expect to reduce number of disk writes for *large* files
"quite a bit". I'm curious how much is that? I wanted to test:
# time cp * /mnt/temp/
# mount tmpfs /mnt/temp -t tmpfs -o size=10G
# time cp * /mnt/temp/
watching `iostat -k 1` but failed. My 2GB RAM was filled pretty quickly
and the system almost died. Anybody feels the power to compare time and
number of kB_wrtn by swap and extfs for the file that's at least twice
as large as physical RAM?

> And I’m suggesting that file managers that extract archives apply
> some heuristics (size of the archive vs. size and current usage of
> /tmp) to determine whether they should use /tmp or /var/tmp.

So you suggest every file/archive manager developers to change their code
(with a not so trivial change) and ignore FHS because debian decided to
change some variable from "no" to "yes" by default? And what's this all
for? What's the benefit?

It does not make them faster:
# mkdir /mnt/temp
# mount tmpfs /mnt/temp -t tmpfs -o size=10G
# cd /mnt/temp
# time tar xf ~/linux-3.4.tar.bz2
real 0m27.100s
user 0m24.327s
sys 0m2.100s
# cd .. ; umount temp ; cd temp
# time tar xf ~/linux-3.4.tar.bz2
real 0m28.072s
user 0m22.103s
sys 0m4.767s
It varies from 26 to 31 seconds between runs, but the result is obvious —
no noticeable difference. User won't notice the speed, but will notice
problems when system becomes heavily swapping or when some apps
break because of not enough space in /tmp.

> ... apply some heuristics ...

Just curious, what heuristics? I've attached a small archive to this
email, can you estimate its unpacked size without unpacking it?

>>I really can't think of any popular application that write a lot of
>>small-only files and can benefit from /tmp being on tmpfs.

> $GUI_BROWSER_DU_JOUR with XTaran’s unburden-home-dir, for example.

`unburden-home-dir` is a bad example:
(a) It's a real corner case (it's the first time I've heard about it)
(b) It can store cache in any directory, not just /tmp
(c) Those files may be really large, so it may also break or make your
system unstable because of tmpfs. And, finally,
(d) it still does not benefit from /tmp being on tmpfs. It's not making
anything noticeably faster because of tmpfs, is it?


PS: there's a major difference between "most programs will still work"
and "most programs will become faster".

You're telling that in many cases apps will still work somehow with /tmp
being on tmpfs. And YOU'RE RIGHT, they will. And if they won't there're
workarouns like TMPDIR. That's true.

What I'm saying is that most apps will work *better* with /tmp being on
real disk, system will use less RAM and be more stable, user won't have
to use any workarounds and *won't lose anything*.

Thanks for reading this HUGE message.

--
Serge

Serge <sergemdev@gmail.com> writes:
> I'm asking for *popular* apps, that create files in /tmp, *never put
> large files* there, and become *noticeably* faster with /tmp on tmpfs?

Is that even the issue, for the most part? My impression is that
using tmpfs is just logistically simpler and safer -- it can be
mounted very early, doesn't muck with the (possibly small or r/o) root
fs, makes it simple to limit temp space without a separate partition,
etc.

-miles

--
「寒ã�„ã�*ã€�ã�¨è©±ã�—ã�‹ã�‘ã‚Œã�°ã€Œå¯’ã�„ã�*〠�ã�¨ç*”ã�ˆã‚‹äººã�®ã�„ã‚‹ã�‚ã�£ã�Ÿã�‹ã�• [俵万智]

On Fri, May 25, 2012 at 02:49:14PM +0100, Will Daniels wrote:
> On 25/05/12 13:52, Ted Ts'o wrote:
> >So what? If you write to a normal file system, it goes into the page
> >cache, which is pretty much the same as writing into tmpfs. In both
> >cases if you have swap configured, the data will get pushed to disk;
>
> That's not at all the same, the page cache is more temporary, it's
> getting flushed to disk pretty quick if memory is tight (presumably)
> but in the same situation using tmpfs going to swap is surely going
> to be more disruptive?

There will be some, but really, not that much difference between going
from tmpfs to swap compared to files written to a filesystem (in both
cases the data is stored in the page cache, whether it's a tmpfs file
or an ext2/3/4 or xfs or btrfs file) in many cases.

The major difference is that tmpfs pages only get written out to swap
when the system is under memory pressure. In contrast, pages which
are backed by a filesystem will start being written to disk after 30
seconds _or_ if the system is under memory pressure.

So if you have a super-fast networking connection, it won't matter;
the download fill the memory very quickly, at which point it will get
written to swap and/or the file location on disk at the same rate,
since you'll be able to download faster than you can save to disk, so
the network connection will get throttled due to TCP/IP backpressure
to roughly the same rate as you are writing to the HDD.

If you have a slow networking connection, it's possible that the 30
second writeback timer will kick off before you start filling the
memory --- but in that case, it's not going to be that disrupting in
the tmpfs case, either. You'll hit memory pressure, and at that point
you'll start writing to disk perhaps a bit later than the 30 second
writeback timer. But at the same time, the download is coming in
slowly enough that you're probably not overwhelming the speed at which
you can write to the HDD or SSD.

The place where it will make a difference is if you have a very large
amount of memory, *and* you are downloading a really big file to /tmp
(substantially bigger than your physical memory), *and* your effective
end-to-end download speed is faster than your HDD write speed, but
slow enough that it takes substantially longer than 30 seconds to
download enough to fill your free physical memory. But that's
actually a pretty narrow window.

> And anyway, not everybody uses swap, in which case this "default" is
> not entirely viable. I, for one, had no idea this had become default
> for Debian and I think it's likely to be one of those things that
> jumps out to bite people who weren't expecting it at some
> inconvenient moment.

Well, it's all about defaults, right? It's easy enough to set up a
swap partition, or even just a swap file by default in the installer.
You can set up a swap file on the fly, so it's not that hard to deal
with it after the fact.

> I'm sure the project veterans and more attentive readers of this
> list are tired of recurring arguments like this, but usually if
> something is recurring it is for a reason. Given my general "no
> swap" preference, I'm glad this has come up again so that I'm aware
> of it this time.
>
> The tmpfs setup seems far more appropriate as a performance tweak
> for admins than as a default. Where there is plenty of RAM, buffer
> cache makes the difference largely negligible. But where there isn't
> an abundance of RAM, it could needlessly cause problems (especially
> without swap).

If you're worried about installations which don't have much memory
(i.e., the 512mb netbook), then swap is absolutely mandatory, I would
think!

And if you consider how much memory most desktop/laptops have, and how
often people **really** are downloading multi-gigabyte files to /tmp
(note that browsers tend to default downloads to ~/Downloads), I
really think the people who are agitating against tmpfs are really
making a much more theoretical argument than one that seems likely to
be hit by an unsophisticated user --- and a sophistcated user can
easily decide whether to use /tmp on disk or not.

- Ted


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

2012/5/26 Miles Bader wrote:

>> I'm asking for *popular* apps, that create files in /tmp, *never put
>> large files* there, and become *noticeably* faster with /tmp on tmpfs?

> Is that even the issue, for the most part? My impression is that
> using tmpfs is just logistically simpler and safer -- it can be
> mounted very early, doesn't muck with the (possibly small or r/o) root
> fs, makes it simple to limit temp space without a separate partition,
> etc.

We're talking about *default* settings. That what makes it an issue.
It won't be an issue if most debian installations were on a small
read-only root and most of them wanted /tmp to be tmpfs because of that.
But it's not. I doubt major part of debians use r/o root and even if they
do, not all of them would like to use tmpfs for that case. Most servers
dedicate separate partitions to /tmp. I had it mount-bound to /home/tmp
in that case. There're many solutions that are fast, use fewer memory,
support quotas... Why tmpfs?

What makes things worse: there're popular programs and popular usecases
that break because of that. It may slow down or even freeze the system
because of heavy swapping. So there must be a strong good reason
surpassing these problems.

I assume people supporting /tmp on tmpfs actually use it that way.
What I don't understand is why they're arguing that "it's not that bad"
instead of just saying why it's good? Does it makes something faster?
What? How many seconds faster? Does it reduces disks operations?
In what cases and how much?

If so many people tested RAMTMP and found no good reasons for it,
then maybe let's change it back to "no" by default? That's what testing
is for anyway?

--
Serge


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

Excerpts from Ted Ts'o's message of 2012-05-25 18:56:55 -0700:
> On Fri, May 25, 2012 at 02:49:14PM +0100, Will Daniels wrote:
> > On 25/05/12 13:52, Ted Ts'o wrote:
> > >So what? If you write to a normal file system, it goes into the page
> > >cache, which is pretty much the same as writing into tmpfs. In both
> > >cases if you have swap configured, the data will get pushed to disk;
> >
> > That's not at all the same, the page cache is more temporary, it's
> > getting flushed to disk pretty quick if memory is tight (presumably)
> > but in the same situation using tmpfs going to swap is surely going
> > to be more disruptive?
>
> There will be some, but really, not that much difference between going
> from tmpfs to swap compared to files written to a filesystem (in both
> cases the data is stored in the page cache, whether it's a tmpfs file
> or an ext2/3/4 or xfs or btrfs file) in many cases.
>
> The major difference is that tmpfs pages only get written out to swap
> when the system is under memory pressure. In contrast, pages which
> are backed by a filesystem will start being written to disk after 30
> seconds _or_ if the system is under memory pressure.
>

On laptops and other power sensitive devices, this is pretty critical.

Hypothetical: I have 2GB of RAM, and I want to watch a 50MB video file
on a connection that will take, say, 10 minutes to cache the whole thing
(and its a 10 minute video).

With a regular filesystem hosting /tmp, Every 30 seconds I will wake up
the hard disk, and write data to it. I doubt most spinning disks will
go to sleep in < 30 seconds, so this is more than 10 minutes solid of
hard disk spinning.

With tmpfs, there is no memory pressure, so my disk never even spins up
to write anything to it. If I do run into memory pressure, yes, I need
to use swap at that point. But at that point I've got a lot more than
just the disk draining power.


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

On Sat, May 26, 2012 at 03:24:02AM +0800, Thomas Goirand wrote:
> > /tmp 8,0G 60M 8,0G 1% /tmp
> > Does this count as "large files"?
> > As "a lot of small-only files"?
> >
> Exactly how is this a practical explanation and example? :/
> Are you saying that in *your case* /tmp is almost unused?
I'm saying that 60M is a substantial amount which still may be not called
"large".

--
WBR, wRAR

On Fri, 25 May 2012 21:56:55 -0400
Ted Ts'o <tytso@mit.edu> wrote:

>
> The major difference is that tmpfs pages only get written out to swap
> when the system is under memory pressure. In contrast, pages which
> are backed by a filesystem will start being written to disk after 30
> seconds _or_ if the system is under memory pressure.
>

I still think the major difference is that page cache -> ext2 can be quota'd while tmpfs -> swap cannot (AFAIK; has that changed in the past couple of years?). This may be good or bad depending on your use case.

>
> And if you consider how much memory most desktop/laptops have, and how
> often people **really** are downloading multi-gigabyte files to /tmp
> (note that browsers tend to default downloads to ~/Downloads)

Browsers write files to ~/Downloads (or ~/Desktop) *when the user selects "Save As"*. On Iceweasel and Chrome at least, if you click a link to a content-type the browser cannot natively display, it downloads it to /tmp while it's waiting for you to tell it what to do with it. These files can be arbitrarily large.

Weldon


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120526073853.d0868690.weldon@b.rontosaur.us">htt p://lists.debian.org/20120526073853.d0868690.weldon@b.rontosaur.us

2012/5/26 Clint Byrum:

> On laptops and other power sensitive devices, this is pretty critical.

> Hypothetical: I have 2GB of RAM, and I want to watch a 50MB video file
> on a connection that will take, say, 10 minutes to cache the whole thing
> (and its a 10 minute video).

> With a regular filesystem hosting /tmp, Every 30 seconds I will wake up
> the hard disk, and write data to it.

There's a much better solution to that: /proc/sys/vm/laptop_mode and
laptop-mode-tools. If you `echo 1 > /proc/sys/vm/laptop_mode` disk
will spin up only when reading. laptop-mode-tools usually also increase
dirty_*_centisecs allowing to not write cache for minutes. So you get
all the benefits of tmpfs without its problems, like heavy swapping or
size limited by memory.

> I doubt most spinning disks will go to sleep in < 30 seconds

Mine spins down in 5 seconds.

--
Serge


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOVenEpJzU+kqpKy5-g7XNA8RH99jOn7aarw43Gfnf-rMO=vRQ@mail.gmail.com">http://lists.debian.org/CAOVenEpJzU+kqpKy5-g7XNA8RH99jOn7aarw43Gfnf-rMO=vRQ@mail.gmail.com