On Mon, 8 Feb 2010, Greg Smith wrote:
Hannu Krosing wrote:
Have you kept trace of what filesystems are in use ?
Almost everything I do on Linux has been with ext3. I had a previous
diversion into VxFS and an upcoming one into XFS that may shed more light on
all this.
it would be nice if
Hannu Krosing wrote:
Have you kept trace of what filesystems are in use ?
Almost everything I do on Linux has been with ext3. I had a previous
diversion into VxFS and an upcoming one into XFS that may shed more
light on all this.
And, yes, the whole I/O scheduling approach in Linux was
Josh Berkus wrote:
FWIW, back when deadline was first introduced Mark Wong did some tests
and found Deadline to be the fastest of 4 on DBT2 ... but only by about
5%. If the read vs. checkpoint analysis is correct, what was happening
is the penalty for checkpoints on deadline was almost wiping ou
On Feb 8, 2010, at 9:49 AM, Josh Berkus wrote:
>
> Those tests were also done on attached storage.
>
> So, what this suggests is:
> reads: deadline > CFQ
> writes: CFQ > deadline
> attached storage: deadline > CFQ
>
From my experience on reads:
Large sequential scans mixed with concurrent r
On Mon, Feb 8, 2010 at 9:49 AM, Josh Berkus wrote:
>
>> That's basically what I've been trying to make clear all along: people
>> should keep an open mind, watch what happens, and not make any
>> assumptions. There's no clear cut preference for one scheduler or the
>> other in all situations. I
On Monday 08 February 2010 19:34:01 Greg Stark wrote:
> On Mon, Feb 8, 2010 at 4:53 AM, Robert Haas wrote:
> > On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
> >
> >> Yeah, it seems there are two patches here -- one is the addition of
> >> fsync_fname() and the other is the fsync_prepare stuff.
On Mon, Feb 8, 2010 at 10:49 AM, Josh Berkus wrote:
>
>> That's basically what I've been trying to make clear all along: people
>> should keep an open mind, watch what happens, and not make any
>> assumptions. There's no clear cut preference for one scheduler or the
>> other in all situations.
On Mon, Feb 8, 2010 at 4:53 AM, Robert Haas wrote:
> On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
>> Yeah, it seems there are two patches here -- one is the addition of
>> fsync_fname() and the other is the fsync_prepare stuff.
Sorry, I'm just catching up on my mail from FOSDEM this past weeke
> That's basically what I've been trying to make clear all along: people
> should keep an open mind, watch what happens, and not make any
> assumptions. There's no clear cut preference for one scheduler or the
> other in all situations. I've seen CFQ do much better, you and Albe
> report situat
Kevin Grittner wrote:
I'll keep this in mind as something to try if we have problem
performance in line with what that page describes, though
That's basically what I've been trying to make clear all along: people
should keep an open mind, watch what happens, and not make any
assumptio
"Albe Laurenz" wrote:
> Greg Smith wrote:
>> http://insights.oetiker.ch/linux/fsopbench/
>
> That is interesting; particularly since I have made one quite
> different experience in which deadline outperformed CFQ by a
> factor of approximately 4.
I haven't benchmarked it per se, but when we s
Greg Smith wrote:
> Recently I've made a number of unsubstantiated claims that the deadline
> scheduler on Linux does bad things compared to CFQ when running
> real-world mixed I/O database tests. Unfortunately every time I do one
> of these I end up unable to release the results due to client
Recently I've made a number of unsubstantiated claims that the deadline
scheduler on Linux does bad things compared to CFQ when running
real-world mixed I/O database tests. Unfortunately every time I do one
of these I end up unable to release the results due to client
confidentiality issues.
Robert Haas wrote:
[explanation of how Oracle locks on Updates involving foreign keys]
>
> Yeah, that seems odd. I assume they know what they're doing; they're
> Oracle, after all. It does sound, too, like they have column level
> locks based on your comment about "an EXCLUSIVE lock on the modif
14 matches
Mail list logo
