Henrique de Moraes Holschuh writes:
> On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
>> Henrique de Moraes Holschuh 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
Wouter Verhelst 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 user /
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
> di
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 ignor
On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
> Henrique de Moraes Holschuh 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 is due
Henrique de Moraes Holschuh 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, T
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 actu
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
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 t
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.
>
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 sh
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
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 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. A
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 f
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.
Stephan Seitz 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 your Debian systems have
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
> s
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
t
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 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 tho
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 th
Wouter Verhelst 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 in filli
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
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.
> >
>
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
Josselin Mouette 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 was
> ena
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
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, th
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 UNS
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
> durabili
> >>> 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 summa
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:
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 Tol
]] 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
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
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
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
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 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" quote
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 suppo
]] 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
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"
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 abo
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-wo
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
Serge 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 quoting above
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
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
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
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" quote
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
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
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 p
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 i
Goswin von Brederlow wrote:
> Uoti Urpala 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 memory is not itself
Uoti Urpala 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; when th
Salvo Tomaselli 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 out yourself
Ben Hutchings 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 this is rea
Salvo Tomaselli 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 hang.
> It's e
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 .
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 uns
> 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 wh
* 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 th
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 i
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
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 swappin
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 d
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 becau
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 rea
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'
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 a
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 here
> 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. Yo
> 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 pr
> 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 p
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 part
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 sm
Josselin Mouette 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 again, it
Salvo Tomaselli 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.
>
Carlos Alberto Lopez Perez 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 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.
Wrong. The threa
Vincent Danjean writes:
> Le 25/05/2012 05:03, Russell Coker a écrit :
>> On Fri, 25 May 2012, 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
Nikolaus Rath writes:
> Thomas Goirand 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 following
Carlos Alberto Lopez Perez 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 heavy fil
Henrique de Moraes Holschuh 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 magnitude.
On Wed, May 30, 2012 at 02:48:26PM +0200, Bjørn Mork wrote:
> Vincent Lefevre 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 a
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
Vincent Lefevre 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 flash
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 #6
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 i
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
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 us
On Mon, 28 May 2012 13:03:47 +0200
Toni Mueller 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?), then / gets t
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 fil
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 unreasonable expectations
>>> of what can be expected to be availa
On Sun, May 27, 2012 at 10:01:22PM +0200, Tollef Fog Heen wrote:
> ]] Thomas Goirand
>
> > Come on, WE CAN! Let's create a /run/tmp *now*, it wont cost us much,
> > then later applications can slowly use it if they want. Worst case:
> > not a lot of app uses it, and the /run/tmp tmpfs isn't used
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 unreasonable expectations
> > of what can be expected to be available (by default).
> >
> We welcome you to r
On Sat, May 26, 2012 at 04:39:34PM -0400, Joey Hess wrote:
> Roger Leigh wrote:
> > I did want to have this for wheezy (#633299). But I lacked the time
> > and familiarity with the d-i code, and the d-i developers also have
> > higher priorities.
>
> Personally, this d-i developer has as one prio
2012/5/27 Adam Borowski wrote:
> First, you're benchmarking the speed of process creation, not of file
> operations. Starting up seq or mv takes ages compared to an in-memory
> file write.
They may be slower than in-memory operations, but they're definitely
faster than fsync(). So if there was f
1 - 100 of 190 matches
Mail list logo
