2012/6/1 Goswin von Brederlow wrote:
All the complaints about /tmp as tmpfs come down to one simple issue:
The size of the tmpfs isn't chosen well.
Mounting /tmp to tmpfs not just breaks a lot of apps and reduces system
stability, but it actually does nothing else. You get no benefits from
On Tue, Jun 05, 2012 at 09:29:46AM +0300, Serge wrote:
2012/6/1 Goswin von Brederlow wrote:
All the complaints about /tmp as tmpfs come down to one simple issue:
The size of the tmpfs isn't chosen well.
Mounting /tmp to tmpfs not just breaks a lot of apps and reduces system
stability,
Mike Hommey m...@glandium.org writes:
On Tue, Jun 05, 2012 at 09:29:46AM +0300, Serge wrote:
2012/6/1 Goswin von Brederlow wrote:
All the complaints about /tmp as tmpfs come down to one simple issue:
The size of the tmpfs isn't chosen well.
Mounting /tmp to tmpfs not just breaks a lot
Serge sergem...@gmail.com writes:
2012/6/1 Goswin von Brederlow wrote:
All the complaints about /tmp as tmpfs come down to one simple issue:
The size of the tmpfs isn't chosen well.
Mounting /tmp to tmpfs not just breaks a lot of apps and reduces system
stability, but it actually does
2012/6/5 Goswin von Brederlow wrote:
You keep claiming tmpfs compromises system stability. Can you show a
kernel oops of a crash caused by tmpfs?
No crashes, system just becomes slow and hard/impossible to use. See the
Stefan Lippers-Hollmann email about tmpfs vs disk writes. System that
does
Serge sergem...@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?
gcc, ocamlopt, mc, lintian
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with
On Thu, May 31, 2012 at 12:46:49AM +0300, Uoti Urpala wrote:
Also, nowadays normal filesystems are journaled; using a journal for
writes to /tmp damages the SSD for zero benefit.
Writing to /tmp will damage a SSD? Are you serious? And writing to /var
or /home will not?
If SSDs are so easy
On 2012-05-25 14:49:14 +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;
2012/5/30 Vincent Lefevre 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
Serge wrote:
you eat cache memory. Meaning, you store /tmp files in cache even when
they're not used, so kernel cannot use that memory to store some useful
files. This increases I/O and makes the system slower.
The tmpfs files will be written to swap if they aren't accessed much and
the kernel
2012/5/31 Uoti Urpala wrote:
you eat cache memory. Meaning, you store /tmp files in cache even when
they're not used, so kernel cannot use that memory to store some useful
files. This increases I/O and makes the system slower.
The tmpfs files will be written to swap if they aren't accessed
On 26 May 2012 19:20, Carlos Alberto Lopez Perez clo...@igalia.com wrote:
*Important*: use df -h /tmp NOT du -hs /tmp, since the flash player
deletes the file entry from /tmp as soon as it gets the inode allocated.
I believe this a measure to prevent piracy (people ripping the video
from /tmp)
Salvo Tomaselli tipos...@tiscali.it writes:
This is indeed a valid point. But that’s no regression; /tmp has
always been for small short-lived files, and /var/tmp for those
that are not one of them or not both.
You just made up this difference.
No he didn't, it's common practice from
On 28/05/12 08:15, Miles Bader wrote:
Salvo Tomaselli tipos...@tiscali.it writes:
This is indeed a valid point. But that’s no regression; /tmp has
always been for small short-lived files, and /var/tmp for those
that are not one of them or not both.
You just made up this difference.
No he
On 05/27/2012 02:55 AM, Mike Hommey wrote:
I hope it isn't, because it's poor security. It's easy to read the
file from /proc/$pid/fd/$num
Mike
If you were to trust Adobe in terms of security, then you'd be the first
person I know to do so.
Jokes set apart, I believe that they just
On 05/27/2012 02:35 AM, François Bottin wrote:
My point is that I can't stand that the major point to not use tmpfs
is caused by a closed source software. If you think it is faulty, then
do not use it!
By the way, I can't reproduce your problem. That's probably due to the
fact that there is
Joey Hess dixit:
If programs that write large files to /tmp are changed to usr /var/tmp,
then over time a system will accumulate orphaned large tmp files in
/var/tmp. Nothing will come along and clean them up.
This is indeed a valid point. But that’s no regression; /tmp has
always been for small
This is indeed a valid point. But that’s no regression; /tmp has
always been for small short-lived files, and /var/tmp for those
that are not one of them or not both.
You just made up this difference.
Nothing nowhere says anything about the size of the files. The only thing
mentioned is the
On 27/05/12 20:01, Thorsten Glaser wrote:
This is indeed a valid point. But that’s no regression; /tmp has
always been for small short-lived files, and /var/tmp for those
that are not one of them or not both.
I am still waiting for someone to tell me where is said that /tmp should
be for small
On Sat, May 26, 2012 at 03:24:02AM +0800, Thomas Goirand wrote:
/tmp 8,0G 60M 8,0G1% /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*
On Fri, 25 May 2012 21:56:55 -0400
Ted Ts'o ty...@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
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
On 05/26/2012 04:40 PM, Andrey Rahmatullin wrote:
On Sat, May 26, 2012 at 03:24:02AM +0800, Thomas Goirand wrote:
/tmp 8,0G 60M 8,0G1% /tmp
Does this count as large files?
As a lot of small-only files?
Exactly how is this a practical
On Sat, May 26, 2012 at 10:47:37PM +0800, Thomas Goirand wrote:
/tmp 8,0G 60M 8,0G1% /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
On 05/26/2012 01:33 PM, Clint Byrum wrote:
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
On 05/26/2012 04:47 PM, Thomas Goirand wrote:
Try playing a 2h video with flash, and see that 60 MB isn't enough...
If Adobe Flash is broken, then fix it!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On 05/26/2012 11:14 PM, François Bottin wrote:
On 05/26/2012 04:47 PM, Thomas Goirand wrote:
Try playing a 2h video with flash, and see that 60 MB isn't enough...
If Adobe Flash is broken, then fix it!
I will let you ask the sources from Adobe, create an
alternative *that works*. I will also
Thomas Goirand z...@debian.org writes:
I will let you ask the sources from Adobe, create an alternative *that
works*. I will also let you fix all the other apps that we mentioned
that have the same kind of issues. But *IN THE MEAN WHILE*, until you
are done with this huge and important work,
On 26/05/12 19:13, Russ Allbery wrote:
Thomas Goirand z...@debian.org writes:
I will let you ask the sources from Adobe, create an alternative *that
works*. I will also let you fix all the other apps that we mentioned
that have the same kind of issues. But *IN THE MEAN WHILE*, until you
are
Carlos Alberto Lopez Perez clo...@igalia.com writes:
On 26/05/12 19:13, Russ Allbery wrote:
I find some of the assertions in this thread confusing. I've been
using tmpfs /tmp on my laptop for quite some time and have watched
hour-long movies via the Adobe Flash player and have never noticed
On 26/05/12 19:43, Russ Allbery wrote:
Carlos Alberto Lopez Perez clo...@igalia.com writes:
On 26/05/12 19:13, Russ Allbery wrote:
I find some of the assertions in this thread confusing. I've been
using tmpfs /tmp on my laptop for quite some time and have watched
hour-long movies via the
Carlos Alberto Lopez Perez clo...@igalia.com writes:
On 26/05/12 19:43, Russ Allbery wrote:
Carlos Alberto Lopez Perez clo...@igalia.com writes:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666096
That bug contains little actual information, not even what software was
being used.
On 05/26/2012 07:08 PM, Thomas Goirand wrote:
On 05/26/2012 11:14 PM, François Bottin wrote:
On 05/26/2012 04:47 PM, Thomas Goirand wrote:
Try playing a 2h video with flash, and see that 60 MB isn't enough...
If Adobe Flash is broken, then fix it!
I will let you ask the sources from
On Sat, May 26, 2012 at 08:20:46PM +0200, Carlos Alberto Lopez Perez wrote:
On 26/05/12 19:43, Russ Allbery wrote:
Carlos Alberto Lopez Perez clo...@igalia.com writes:
On 26/05/12 19:13, Russ Allbery wrote:
I find some of the assertions in this thread confusing. I've been
using tmpfs
Ted Ts'o wrote:
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!
Not really. I have no legitimate programs that use more than 50% of my 1 gb.
I have an SSD. So why enable swap? If chromium goes
Henrique de Moraes Holschuh dixit:
On Fri, 25 May 2012, Thomas Goirand wrote:
for small files, and in that case, it's faster. In reality, it's
not that much faster, thanks to Linux caching of the filesystem,
Under heavy filesystem IO load, yes it is. By several orders of magnitude.
Not just
2012/5/25 Thorsten Glaser wrote:
It’s faster because the files don’t even get written to disc if
they’re kept for, say, five minutes, and aren’t just short-lived.
Theoretically, yes. But I'm not asking to forbid everybody to use
tmpfs. We're talking about defaults and about the most used test
On Fri, May 25, 2012 at 03:50:31PM +0300, Serge wrote:
/tmp on tmpfs won't help in that case. You do not reduce number of disk
writes, you just move them to other directories. As you suggested, all
the programs will still use files i.e. in /var/tmp. Or they'll write to
swap if tmpfs is large
On 25/05/12 13:50, Serge wrote:
Again, I'm not asking to drop this feature. I'm asking to have it disabled
*by default* but supported by debian installer, so really smart people,
that know what may be broken by it, but really need it, could enable it.
+1
On 25/05/12 13:52, Ted Ts'o wrote:
2012/5/25 Andrey Rahmatullin wrote:
Why do you assume tmpfs contents is always written to the swap?
Most programs, using /tmp for temporary files, may write *large* files
there. So most programs fill tmpfs with large files. So tmpfs grows and
swaps out (probably swapping out other applications
On Fri, May 25, 2012 at 05:08:37PM +0300, Serge wrote:
Why do you assume tmpfs contents is always written to the swap?
Most programs, using /tmp for temporary files, may write *large* files
there. So most programs fill tmpfs with large files. So tmpfs grows and
swaps out (probably swapping
Serge dixit:
cases. 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
On 05/25/2012 10:20 PM, Andrey Rahmatullin wrote:
/tmp 8,0G 60M 8,0G1% /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?
On 05/26/2012 12:21 AM, Thorsten Glaser wrote:
What you want is
to optimise for a corner case.
Ah... So Mysql, flash videos, mc, image editors,
cd burners, and all the (very common) examples
he gave are just corner cases in your book?
We must have very different readings...
Thomas
--
To
Serge sergem...@gmail.com writes:
Every tool either supports setting TMPDIR=/var/tmp before running
it or is buggy. Go fix these instead
Do I understand you right? You suggest every tool that need large
tmp files to use /var/tmp instead?
That's not a new suggestion, it's been standard
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
Serge sergem...@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 --
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
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
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.
50 matches
Mail list logo
