On Tuesday February 19, [EMAIL PROTECTED] wrote:
> On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote:
> > First, I still don't understand why in God's sake barriers are "working"
> > while regular cache flushes are not. Almost no consumer-grade hard drive
> > supports write
On Monday February 18, [EMAIL PROTECTED] wrote:
>
>
> I'll put it even more strongly. My experience is that disabling write
> cache plus disabling barriers is often much faster than enabling both
> barriers and write cache enabled, when doing metadata intensive
> operations, as long as you have
Jeremy Higdon wrote:
On Tue, Feb 19, 2008 at 09:16:44AM +1100, David Chinner wrote:
On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote:
First, I still don't understand why in God's sake barriers are "working"
while regular cache flushes are not. Almost no consumer-grade hard
Jeremy Higdon wrote:
On Tue, Feb 19, 2008 at 09:16:44AM +1100, David Chinner wrote:
On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote:
First, I still don't understand why in God's sake barriers are working
while regular cache flushes are not. Almost no consumer-grade hard drive
On Monday February 18, [EMAIL PROTECTED] wrote:
I'll put it even more strongly. My experience is that disabling write
cache plus disabling barriers is often much faster than enabling both
barriers and write cache enabled, when doing metadata intensive
operations, as long as you have a
On Tuesday February 19, [EMAIL PROTECTED] wrote:
On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote:
First, I still don't understand why in God's sake barriers are working
while regular cache flushes are not. Almost no consumer-grade hard drive
supports write barriers, but
> My complaint about having to support them within dm when more than one
> device is involved is because any efficiencies disappear: you can't send
> further I/O to any one device until all the other devices have completed
> their barrier (or else later I/O to that device could overtake the
>
My complaint about having to support them within dm when more than one
device is involved is because any efficiencies disappear: you can't send
further I/O to any one device until all the other devices have completed
their barrier (or else later I/O to that device could overtake the
barrier
Jeremy Higdon wrote:
[]
> I'll put it even more strongly. My experience is that disabling write
> cache plus disabling barriers is often much faster than enabling both
> barriers and write cache enabled, when doing metadata intensive
> operations, as long as you have a drive that is good at
On Tue, Feb 19, 2008 at 09:16:44AM +1100, David Chinner wrote:
> On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote:
> > First, I still don't understand why in God's sake barriers are "working"
> > while regular cache flushes are not. Almost no consumer-grade hard drive
> > supports
On Tue, Feb 19, 2008 at 02:56:43AM +, Alasdair G Kergon wrote:
> On Tue, Feb 19, 2008 at 09:16:44AM +1100, David Chinner wrote:
> > Surely any hardware that doesn't support barrier
> > operations can emulate them with cache flushes when they receive a
> > barrier I/O from the filesystem
>
On Tue, Feb 19, 2008 at 09:16:44AM +1100, David Chinner wrote:
> Surely any hardware that doesn't support barrier
> operations can emulate them with cache flushes when they receive a
> barrier I/O from the filesystem
My complaint about having to support them within dm when more than one
On Mon, Feb 18, 2008 at 08:52:10AM -0500, Ric Wheeler wrote:
> I understand that. Most of the time, dm or md devices are composed of
> uniform components which will uniformly support (or not) the cache flush
> commands used by barriers.
As a dm developer, it's "almost none of the time" because
On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote:
> First, I still don't understand why in God's sake barriers are "working"
> while regular cache flushes are not. Almost no consumer-grade hard drive
> supports write barriers, but they all support regular cache flushes, and
> the
Michael Tokarev wrote:
Ric Wheeler wrote:
Alasdair G Kergon wrote:
On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
I wonder if it's worth the effort to try to implement this.
My personal view (which seems to be in
Ric Wheeler wrote:
> Alasdair G Kergon wrote:
>> On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
>>> On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
I wonder if it's worth the effort to try to implement this.
>>
>> My personal view (which seems to be in the
Alasdair G Kergon wrote:
On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
I wonder if it's worth the effort to try to implement this.
My personal view (which seems to be in the minority) is that it's a
waste of our
Alasdair G Kergon wrote:
On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
I wonder if it's worth the effort to try to implement this.
My personal view (which seems to be in the minority) is that it's a
waste of our
Ric Wheeler wrote:
Alasdair G Kergon wrote:
On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
I wonder if it's worth the effort to try to implement this.
My personal view (which seems to be in the minority) is that
Michael Tokarev wrote:
Ric Wheeler wrote:
Alasdair G Kergon wrote:
On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
I wonder if it's worth the effort to try to implement this.
My personal view (which seems to be in
On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote:
First, I still don't understand why in God's sake barriers are working
while regular cache flushes are not. Almost no consumer-grade hard drive
supports write barriers, but they all support regular cache flushes, and
the latter
On Mon, Feb 18, 2008 at 08:52:10AM -0500, Ric Wheeler wrote:
I understand that. Most of the time, dm or md devices are composed of
uniform components which will uniformly support (or not) the cache flush
commands used by barriers.
As a dm developer, it's almost none of the time because
On Tue, Feb 19, 2008 at 09:16:44AM +1100, David Chinner wrote:
Surely any hardware that doesn't support barrier
operations can emulate them with cache flushes when they receive a
barrier I/O from the filesystem
My complaint about having to support them within dm when more than one
device
On Tue, Feb 19, 2008 at 02:56:43AM +, Alasdair G Kergon wrote:
On Tue, Feb 19, 2008 at 09:16:44AM +1100, David Chinner wrote:
Surely any hardware that doesn't support barrier
operations can emulate them with cache flushes when they receive a
barrier I/O from the filesystem
My
Jeremy Higdon wrote:
[]
I'll put it even more strongly. My experience is that disabling write
cache plus disabling barriers is often much faster than enabling both
barriers and write cache enabled, when doing metadata intensive
operations, as long as you have a drive that is good at CTQ/NCQ.
On Tue, Feb 19, 2008 at 09:16:44AM +1100, David Chinner wrote:
On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote:
First, I still don't understand why in God's sake barriers are working
while regular cache flushes are not. Almost no consumer-grade hard drive
supports write
> And don't RH distributions install with LVM by default these days?
> For those it should be the standard case too on all systems with
> only a single disk.
Yes - I make a point of turning it off ;)
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Fri, Feb 15, 2008 at 02:12:29PM +, Alasdair G Kergon wrote:
> On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
> > On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
> > > I wonder if it's worth the effort to try to implement this.
>
> My personal view (which seems
On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
> On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
> > I wonder if it's worth the effort to try to implement this.
My personal view (which seems to be in the minority) is that it's a
waste of our development time *except*
On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
I wonder if it's worth the effort to try to implement this.
My personal view (which seems to be in the minority) is that it's a
waste of our development time *except* in
On Fri, Feb 15, 2008 at 02:12:29PM +, Alasdair G Kergon wrote:
On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
I wonder if it's worth the effort to try to implement this.
My personal view (which seems to be
And don't RH distributions install with LVM by default these days?
For those it should be the standard case too on all systems with
only a single disk.
Yes - I make a point of turning it off ;)
Alan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
32 matches
Mail list logo