Wouter Verhelst wou...@debian.org writes:
On Sun, Jun 24, 2012 at 09:54:22PM +0200, Stephan Seitz wrote:
On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote:
Meanwhile, you've got a non-FHS directory on your system that is of no
immediate use.
Your later suggested /store as a
Henrique de Moraes Holschuh h...@debian.org writes:
On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
I've read that some SSDs really *dislike* the way Linux does TRIM
batching (or doesn't :p), so yes, it may well be that on most SSDs
Henrique de Moraes Holschuh h...@debian.org writes:
On Sun, 24 Jun 2012, Osamu Aoki wrote:
On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:
Tollef Fog Heen wrote:
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200,
On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
I've read that some SSDs really *dislike* the way Linux does TRIM
batching (or doesn't :p), so yes, it may well be that on most SSDs
regular fstrim will do much better.
I'm assuming this
On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote:
On Thu, Jun 21, 2012 at 03:46:16PM +0200, Stephan Seitz wrote:
So most of your Debian systems have several users working at the
same time on the same system? Okay, then you have a different user
base.
webserver.
Sorry, I
On Sun, Jun 24, 2012 at 09:54:22PM +0200, Stephan Seitz wrote:
On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote:
Meanwhile, you've got a non-FHS directory on your system that is of no
immediate use.
Your later suggested /store as a user /tmp replacement is a non-FHS
directory
Tollef Fog Heen wrote:
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all trimming functions,
even if your SSD partition is using LUKS and
On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:
Tollef Fog Heen wrote:
You need to enable it in all layers (fstab, crypttab, lvm.conf), yes.
For now you shouldn't use discard option with SSDs, it's bad for
performance. Better is to run fstrim periodically.
Does this mean you
On Thu, Jun 21, 2012 at 03:46:16PM +0200, Stephan Seitz wrote:
On Thu, Jun 21, 2012 at 09:06:30AM +0200, Wouter Verhelst wrote:
Maybe, but we are talking about defaults. Please correct me, but I
think that most Debian systems are in some way single user systems.
Not in my experience.
So
On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:
Tollef Fog Heen wrote:
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all
On Sun, 24 Jun 2012, Osamu Aoki wrote:
On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:
Tollef Fog Heen wrote:
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will
2012/6/19 Wouter Verhelst wrote:
That's not true. Only applications, that are limited by /tmp speed will
become faster then. Do you know such applications?
Any application which performs I/O anywhere has a chance of being
limited by it.
In theory. But do you know any applications actually
On Mi, 20 iun 12, 15:18:55, Stephan Seitz wrote:
Fine let’s talk. Why can’t we find a compromise? Additional to our
disk /tmp we create a /ramtmp (so the name suggests that this tmp is
a ramdisk) with tmpfs. This should be doable in time for Wheezy. The
release notes should mention it. And
On Fri, 22 Jun 2012, Andrei POPESCU wrote:
On Mi, 20 iun 12, 15:18:55, Stephan Seitz wrote:
Fine let’s talk. Why can’t we find a compromise? Additional to our
disk /tmp we create a /ramtmp (so the name suggests that this tmp is
a ramdisk) with tmpfs. This should be doable in time for
On Wed, Jun 20, 2012 at 03:18:55PM +0200, Stephan Seitz wrote:
On Mon, Jun 18, 2012 at 11:42:06PM +0200, Wouter Verhelst wrote:
If you write to /tmp on disk and someone or something calls sync at
precisely the wrong moment, you're stuck, and your performance suffers.
Not so with tmpfs.
On Thu, Jun 21, 2012 at 09:06:30AM +0200, Wouter Verhelst wrote:
Maybe, but we are talking about defaults. Please correct me, but I
think that most Debian systems are in some way single user systems.
Not in my experience.
So most of your Debian systems have several users working at the same
Dnia 2012-06-21, czw o godzinie 09:06 +0200, Wouter Verhelst pisze:
[ cut ]
Yes; but if you're going to make /tmp be a separate partition, then your
argument that there's more space on disk doesn't really hold anymore,
either, since now /tmp is much much smaller than your disk (I've never
seen
Stephan Seitz stse+deb...@fsing.rootsland.net writes:
On Thu, Jun 21, 2012 at 09:06:30AM +0200, Wouter Verhelst wrote:
Maybe, but we are talking about defaults. Please correct me, but I
think that most Debian systems are in some way single user systems.
Not in my experience.
So most of
On Wed, Jun 20, 2012 at 09:08:51PM +0200, Carlos Alberto Lopez Perez wrote:
On 20/06/12 15:18, Stephan Seitz wrote:
Fine let’s talk. Why can’t we find a compromise? Additional to our disk
/tmp we create a /ramtmp (so the name suggests that this tmp is a
ramdisk) with tmpfs. This should
On Thu, Jun 21, 2012 at 10:20:03PM +0200, David Weinehall wrote:
because I think it'd be impossible to convince some people that /tmp
isn't a random dumping ground for anything and everything.
But what is /tmp for you? Since my first Unix experience in the 90s, /tmp
was always the local disk
On Mon, Jun 18, 2012 at 11:42:06PM +0200, Wouter Verhelst wrote:
If you write to /tmp on disk and someone or something calls sync at
precisely the wrong moment, you're stuck, and your performance suffers.
Not so with tmpfs.
Maybe, but we are talking about defaults. Please correct me, but I
On 20/06/12 15:18, Stephan Seitz wrote:
Fine let’s talk. Why can’t we find a compromise? Additional to our disk
/tmp we create a /ramtmp (so the name suggests that this tmp is a
ramdisk) with tmpfs. This should be doable in time for Wheezy. The
release notes should mention it. And those who
Wouter Verhelst wou...@debian.org writes:
On Wed, Jun 13, 2012 at 04:14:52AM +0300, Serge wrote:
User cannot break the system filling /tmp on disk. But he can do that
if he fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of
failure for servers.
No, that's not true. The real danger
On Wed, Jun 13, 2012 at 04:14:52AM +0300, Serge wrote:
2012/6/10 Wouter Verhelst wrote:
A lot of people (including you) said that tmpfs makes things faster. But
there were no examples of popular use-cases becoming faster because
of /tmp on tmpfs, so I had nothing to quote.
You're not
Wouter Verhelst wrote:
I don't think compiling C code has been CPU bound since before I was
born (and I was born in the late 70s, so that's quite a while). C++ is a
different matter, but still.
Bullshit. GCC uses a lot of CPU unless you compile without optimization,
and is surprisingly slow
Le mercredi 13 juin 2012 à 04:14 +0300, Serge a écrit :
Yes. Everything. Every popular /tmp usage that most users expect to work
is limited either by CPU (gcc compiling) or by network speed (browser or
flash temporaries), or is just too fast already (bash heredoc). So moving
/tmp to tmpfs
Josselin Mouette j...@debian.org writes:
Le jeudi 07 juin 2012 à 15:48 +0100, Ben Hutchings a écrit :
There's no need to be a dick about it.
Because this discussion was all about not being a dick to begin with, of
course.
Remind me who, in absence of consensus, explained that if tmpfs
On Wed, 2012-06-13 at 09:22 +0200, Josselin Mouette wrote:
Le mercredi 13 juin 2012 à 04:14 +0300, Serge a écrit :
Yes. Everything. Every popular /tmp usage that most users expect to work
is limited either by CPU (gcc compiling) or by network speed (browser or
flash temporaries), or is
2012/6/10 Wouter Verhelst wrote:
A lot of people (including you) said that tmpfs makes things faster. But
there were no examples of popular use-cases becoming faster because
of /tmp on tmpfs, so I had nothing to quote.
You're not even trying.
if tmpfs is faster than (say) ext4, then
Le dimanche 10 juin 2012 à 01:51 +0300, Serge a écrit :
Some people asked for a thread summary. So here it is.
/tmp on tmpfs is good quotes
==
No real quotes here.
So much for a thread summary.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To
On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote:
Some people asked for a thread summary. So here it is.
[Lots of drivel, including thoroughly debunked statements, snipped.
Seriously, can't you even read what's written to you? Sorry for being
angry, but there's a limit to how many times you
On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote:
Some people asked for a thread summary. So here it is.
Sorry, but this is a biased summary, and therefore useless for what it
intends to be.
[...]
/tmp on tmpfs is good quotes
==
No real quotes here. Most of
2012/6/10 Adam Borowski wrote:
Some people asked for a thread summary. So here it is.
Seriously, can't you even read what's written to you?
Yes, I know it was a biased summary. So as yours. But there's a difference
between mine and yours. Mine is based on some real-world applications,
yours is
Serge sergem...@gmail.com writes:
2012/6/10 Adam Borowski wrote:
Some people asked for a thread summary. So here it is.
Seriously, can't you even read what's written to you?
Yes, I know it was a biased summary.
I think you might start to piss off a few people now...
Look at what you are
2012/6/10 Wouter Verhelst wrote:
Sorry, but this is a biased summary, and therefore useless for what it
intends to be.
Yes, I know. It's biased toward the /tmp and real-world applications.
/tmp on tmpfs is good quotes
No real quotes here. Most of this and other threads were about why
/tmp
Serge wrote:
2012/6/10 Adam Borowski wrote:
Some people asked for a thread summary. So here it is.
Seriously, can't you even read what's written to you?
Yes, I know it was a biased summary. So as yours. But there's a difference
between mine and yours. Mine is based on some real-world
On Sun, Jun 10, 2012 at 12:35:47PM +0200, Adam Borowski wrote:
* Less wear of SSD drives.
• Contrary to Serge's claims, SSDs are not an oddity, and it's not
unlikely these will be a majority before wheezy becomes oldstable.
He didn’t say they were oddities. He said you should more worry
2012/6/10 Uoti Urpala wrote:
Yes, I know it was a biased summary. So as yours. But there's a difference
between mine and yours. Mine is based on some real-world applications,
You've posted blatantly false claims. If you post claims like 1+1
equals 2 because the moon is made of cheese, then
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all trimming functions,
even if your SSD partition is using LUKS and LVM?
Depends on what you mean by out of the box. I suspect you still need to
turn on discard support (since it has security implications). It does
not require
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all trimming functions,
even if your SSD partition is using LUKS and LVM?
Depends on what you mean by out of the box. I suspect you still need to
turn on discard
On Sun, Jun 10, 2012 at 06:13:24PM +0300, Serge wrote:
2012/6/10 Wouter Verhelst wrote:
Sorry, but this is a biased summary, and therefore useless for what it
intends to be.
Yes, I know. It's biased toward the /tmp and real-world applications.
/tmp on tmpfs is good quotes
No real
On 06/10/2012 11:55 PM, Stephan Seitz wrote:
Well, if I start Virtual Box on my notebook (4 GB RAM), the system
uses the swap partition.
Frankly, I don't know what the fuck virtualbox is doing
with its memory management, but I was tempted more than
once to file a RC bug with a title like this
On Sun, Jun 10, 2012 at 12:35:47PM +0200, Adam Borowski wrote:
On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote:
Some people asked for a thread summary. So here it is.
But, for the rest of us, here's a different summary.
I've long thought that the wiki might be a good tool for trying to
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all trimming functions,
even if your SSD partition is using LUKS and LVM?
Depends on what you mean by
Serge wrote:
2012/6/10 Uoti Urpala wrote:
You've posted blatantly false claims. If you post claims like 1+1
equals 2 because the moon is made of cheese, then you're a moron, even
if 1+1 does equal 2.
(I like this example :)) It could be, it's impossible to know everything
in the world,
]] Philipp Kern
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all trimming functions,
even if your SSD partition is using LUKS and LVM?
On Sun, Jun 10, 2012 at 10:31:21PM +0200, Tollef Fog Heen wrote:
Well, nice to hear, but I thought, discard was needed in all layers,
so in my example in LUKS, then in LVM and then in the filesystem. Or
is his only a function you activate via hdparm?
It's available in all layers, but as
2012/6/10 Thomas Goirand wrote:
Let's put it this way: I can't run Virtualbox AND
Firefox at the same time, or my laptop becomes unusably
slow and non responsive.
Do you use 2.6 kernel and have FF profile and VB images on the same ext4
partition?
Can you reproduce that with 3.2 kernel?
PS:
Some people asked for a thread summary. So here it is.
Seriously, can't you even read what's written to you?
Yes, I know it was a biased summary.
I think you might start to piss off a few people now...
Look at what you are quoting above. You introduced your biased summary
like this:
2012/6/10 Uoti Urpala wrote:
What false claim are you talking about?
The problem is that you've posted quite a few of those false claims
[...]
For example, the page you linked for your SSDs can take 50 years
of writing before they wear out claim has a first paragraph saying
durability IS
Some people asked for a thread summary. So here it is.
Contents
* Short Problem Summary
* My point
* Initial suggestion - RAMTMP=no + d-i extension
* Later suggestion - RAMTMP=auto
* Other ideas
* Alternatives
- SSD setup - Normal
- SSD setup - Paranoid
* /tmp on tmpfs is good quotes
Le mercredi 06 juin 2012 à 19:56 -0400, Joey Hess a écrit :
A lot of people came down on the pro-tmpfs side in this thread. You have
some good reasons to want to make it available to users. I just wanted
to invite you to make it easier for users to enable tmpfs where
appropriate -- d-i's
On Thu, 2012-06-07 at 09:37 +0200, Josselin Mouette wrote:
Le mercredi 06 juin 2012 à 19:56 -0400, Joey Hess a écrit :
A lot of people came down on the pro-tmpfs side in this thread. You have
some good reasons to want to make it available to users. I just wanted
to invite you to make it
Le jeudi 07 juin 2012 à 15:48 +0100, Ben Hutchings a écrit :
There's no need to be a dick about it.
Because this discussion was all about not being a dick to begin with, of
course.
Remind me who, in absence of consensus, explained that if tmpfs was
enabled by default, he would forcefully make
So RAMTMP now defaults to off. I know it can be hard to give ground on
something you've invested a lot of work into, so Roger Leigh has my
respect for taking this thread into consideration.
A lot of people came down on the pro-tmpfs side in this thread. You have
some good reasons to want to make
Salvo Tomaselli tipos...@tiscali.it writes:
If anyone wants to experience that then write out some GB of data over
NFS. After a short while processes will hang while others keep running.
True, that's what i was saying.
But if there is not enough memory, it's not only one process that will
Ben Hutchings b...@decadent.org.uk writes:
On Fri, Jun 01, 2012 at 11:19:40PM +0200, Carlos Alberto Lopez Perez wrote:
On 01/06/12 13:33, Goswin von Brederlow wrote:
I don't know the ultimate reason behind this ugly behaviour of Linux
when the swapping process is happening, but I know
Salvo Tomaselli tipos...@tiscali.it writes:
No, tmpfs will be swapped out if you don't use a file for a while but
something else uses memory, including IO caching.
unless too many things want to use memory, then tmpfs gives a great
contribution in taking down the machine.
As you pointed
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Goswin von Brederlow wrote:
Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit :
There is one significant difference though. When you read data back to
memory from swap, the kernel does not remember that it already exists on
disk;
Goswin von Brederlow wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
I haven't read the relevant kernel code, but that doesn't match the
behavior I see. Reading a large file from tmpfs and then allocating
memory results in large swap writes every time, even if the newly
allocated
Roger Leigh wrote:
OK, some benchmarks were requested in this thread in a few places.
No, a lack of premature optimisation was requested.
When one is engaged in premature optimisation, one does lots of
benchmarks, and finds things that seem to speed up nicely, and
has many happy nice numbers
2012/6/2 Roger Leigh wrote:
These tests were all performed on current unstable using a core2 quad
core system with ext4 and swap on LVM on a 1 TiB MD RAID1 PV, and
Btrfs internally using RAID1 over 2 1TiB partitions.
Well, not fair for btrfs, but anyway, finally, some tests! Thank you
for
2012/6/2 Carlos Alberto Lopez Perez wrote:
IMHO The logical way of behaving in such situation is to slow-down the
IO bandwidth of the processes that are filling the cache, by sending to
sleep any process that requests more IO while the cache is full instead
of trying to free RAM by swapping
On 06/01/2012 06:50 PM, Goswin von Brederlow wrote:
There is also no problem with having large files in tmpfs. Only
requirement is that you make tmpfs large enough and add enough ram
and/or swap to cope with it.
Well, there's the problem that it will take some memory at least. So
either your
Hi Thomas,
On Sat, Jun 02, 2012 at 07:33:26PM +0800, Thomas Goirand wrote:
All the complaints about /tmp as tmpfs come down to one simple issue:
The size of the tmpfs isn't chosen well. It would be more constructive
to find a better heuristic for the size there.
No. The complain is that
* Toni Mueller [2012-06-02 13:46:19 +0200] wrote:
My suggested fix for this problem is to install a ~/tmp upon account
creation, and set the TEMP environment variable in, say,
/etc/environments. That *should* fix up all cases except for rogue
applications that don't honour $TEMP. We can then
that problem applies to disks as well, and especially to small /
partitions, if you don't have /tmp somewhere else.
But by default the installer doesn't create a small / partition, it uses all
the available space.
So by default just by clicking next-next, there are no such problems.
Users who
Hi
Now lets do a benchmark on a busy system (during a kernel compile) and
some memory pressure, due to building on tmpfs. While this is not
directly representative for /tmp/ usage patterns, it does show what
happens if /tmp/ gets full and fights against normal RAM uses.
Tested on a current
Henrique de Moraes Holschuh h...@debian.org writes:
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
Carlos Alberto Lopez Perez clo...@igalia.com writes:
On 25/05/12 12:14, Henrique de Moraes Holschuh wrote:
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
Nikolaus Rath nikol...@rath.org writes:
Thomas Goirand z...@debian.org writes:
On 05/25/2012 05:33 PM, Mehdi Dogguy wrote:
What if we're installing Debian on a very small system, and that we
need operations with big files in /tmp?
Increase your swap?
So, in this case, we will have the
Vincent Danjean vdanjean...@free.fr writes:
Le 25/05/2012 05:03, Russell Coker a écrit :
On Fri, 25 May 2012, Serge sergem...@gmail.com wrote:
Q: /tmp on tmpfs increases apps performance.
A: What apps? Real apps don't write files during performance-critical
operations. Even if they do,
Salvo Tomaselli tipos...@tiscali.it writes:
Because paging out a couple Gigabytes is veery different from
writing a couple Gigabytes to disk, of course.
Yes because writing that on disk will only block the thread performing the
write, not every thread that tries to allocate memory.
Carlos Alberto Lopez Perez clo...@igalia.com writes:
On 25/05/12 12:20, Henrique de Moraes Holschuh wrote:
On Fri, 25 May 2012, Salvo Tomaselli wrote:
Because paging out a couple Gigabytes is veery different from
writing a couple Gigabytes to disk, of course.
Yes because writing that on
Salvo Tomaselli tipos...@tiscali.it writes:
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.
tmpfs will make it stay forever in the RAM, caches are flushed to disk and
their space can be used for new things.
Josselin Mouette j...@debian.org writes:
Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit :
There is one significant difference though. When you read data back to
memory from swap, the kernel does not remember that it already exists on
disk; when the data is evicted from memory
On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote:
On 05/28/2012 05:32 AM, Roger Leigh wrote:
On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote:
On 05/25/2012 07:44 PM, Roger Leigh wrote:
However, the majority of
software which finds the tmpfs too small has
On Fri, May 25, 2012 at 12:44:03PM +0100, Roger Leigh wrote:
On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
I've read across different debates about whether using tmpfs is good or bad
but I could not find the most important reason, so here it is...
I haven't got anything
If anyone wants to experience that then write out some GB of data over
NFS. After a short while processes will hang while others keep running.
True, that's what i was saying.
But if there is not enough memory, it's not only one process that will hang.
It's everything.
So i think that adding
No, tmpfs will be swapped out if you don't use a file for a while but
something else uses memory, including IO caching.
unless too many things want to use memory, then tmpfs gives a great
contribution in taking down the machine.
As you pointed out yourself in another email, under memory
And you are not correct here. The tmpfs defaults to guaranteeing
a certain fixed size being available, as I stated above. If the
memory was used up by applications and data, then the system will
swap, drop cached data, flush unwritten data to disc etc. in order
to make room for it. You
2012/6/1 Roger Leigh wrote:
I'm certainly not averse to switching the default back, if this is the
best solution at the present time for the majority of our users.
If only it was the best solution...
As was seen in both this an earlier discussions, there is not a clear-cut
consensus
Goswin von Brederlow wrote:
Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit :
There is one significant difference though. When you read data back to
memory from swap, the kernel does not remember that it already exists on
disk; when the data is evicted from memory again, it
On 01/06/12 13:33, Goswin von Brederlow wrote:
I don't know the ultimate reason behind this ugly behaviour of Linux
when the swapping process is happening, but I know this is real and it
happens because I have experimented this situation myself more than a
couple of times.
It's a matter
On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
Q: /tmp on tmpfs increases apps performance.
A: What apps? Real apps don't write files during performance-critical
operations. Even if they do, they write large files. And large files are
written faster when they're written on real
On Fri, Jun 01, 2012 at 11:19:40PM +0200, Carlos Alberto Lopez Perez wrote:
On 01/06/12 13:33, Goswin von Brederlow wrote:
I don't know the ultimate reason behind this ugly behaviour of Linux
when the swapping process is happening, but I know this is real and it
happens because I have
Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a
écrit :
With tmpfs on /tmp you are breaking many applications that assume that
they have enough space to write on /tmp like the flash player ( see
Debian bug #666096 ) or cdrecord software ( see #665634 ).
Seriously, this is
On 2012-05-30 12:08:29 +0200, Josselin Mouette wrote:
Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a
écrit :
With tmpfs on /tmp you are breaking many applications that assume that
they have enough space to write on /tmp like the flash player ( see
Debian bug #666096 )
Vincent Lefevre vinc...@vinc17.net writes:
On 2012-05-30 12:08:29 +0200, Josselin Mouette wrote:
Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a
écrit :
With tmpfs on /tmp you are breaking many applications that assume that
they have enough space to write on /tmp like the
On Wed, May 30, 2012 at 02:48:26PM +0200, Bjørn Mork wrote:
Does that make any difference at all? If an application is unable to
handle the out-of-space condition, then it will be unable to handle the
out-of-space condition no matter how big the file system is. Increasing
the file system
On Wed, May 30, 2012 at 02:48:26PM +0200, Bjørn Mork wrote:
Vincent Lefevre vinc...@vinc17.net writes:
On 2012-05-30 12:08:29 +0200, Josselin Mouette wrote:
Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a
écrit :
With tmpfs on /tmp you are breaking many applications
On Mon, May 28, 2012 at 08:26:52AM -0400, Weldon Goree wrote:
at some point). Much better developers than me seem to have formed
this opinion too (cf browsers' behavior while it waits for you to tell
it what to do with an unknown content-type: it's a disk-based pipe to
whatever program you
Hi,
On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
What's a temporary file? Really, why would applications temporarily store
its data in a file? They do that to *free some memory*. Placing those files
back to memory renders the whole process of writing the file useless.
If the files
On Mon, 28 May 2012 13:03:47 +0200
Toni Mueller t...@debian.org wrote:
It's not, see below. Also, most of the time, /tmp goes into / (on
smaller systems), and is thus typically *very* much limited in space.
If the theory is to design for the trained chicken install (and it still is,
right?),
On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote:
As you wrote, nothing is infinite. I don't think that /tmp is worse than
/home like other said. Your /home could become full as well.
Your /home could be a network share like NFS and /tmp a local partition,
so you don’t want to
On Sat, May 26, 2012 at 10:59:06PM -0400, Joey Hess wrote:
Adam Borowski wrote:
I think that box had jfs, but other filesystems are no different: for
example, ext* will fsync() during a rename() call behind your back even if
you don't request it, forcing every file to hit the disk platters
On Sun, May 27, 2012 at 05:21:04AM +0300, Serge wrote:
2012/5/27 Adam Borowski wrote:
I think that box had jfs, but other filesystems are no different: for
example, ext* will fsync() during a rename() call behind your back even
if you don't request it, forcing every file to hit the disk
On Sat, 26 May 2012, Joey Hess wrote:
Henrique de Moraes Holschuh wrote:
In fact it is the other way. We have /var/tmp for the large file since
about forever, and important platforms that have /tmp in memory since the
early 2000's (Solaris)
And that STILL wasn't enough for people
On Sat, 26 May 2012, Carlos Alberto Lopez Perez wrote:
So please, don't argue about theoretical things about virtual memory or
IO schedulers. If you are a desktop Linux user, you should know how ugly
the things get when the system is swapping.
Mine is not that annoying, but certainly not
On 05/27/2012 04:32 AM, Russ Allbery wrote:
The root problem here is that we have multiple parameters that we want to
set on temporary storage:
1. Space for dumping arbitrary files without assuming anything about the
structure of the user's home directory.
2. Fast space for small
1 - 100 of 190 matches
Mail list logo
