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,
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 drive
On Tue, Feb 19, 2008 at 02:39:00AM +, Alasdair G Kergon wrote:
> > For example, how safe
> > xfs is if barriers are not supported or turned off?
>
> The last time we tried xfs with dm it didn't seem to notice -EOPNOTSUPP
> everywhere it should => recovery may find corruption.
Bug reports, p
> 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
> barri
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/NC
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 w
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
devic
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 Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
> Alasdair G Kergon wrote:
> > On Fri, Feb 15, 2008 at 01:08:21PM +0100, Andi Kleen wrote:
> >> Implement barrier support for single device DM devices
> > Thanks. We've got some (more-invasive) dm patches in the works that
> > attemp
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 la
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 t
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 minorit
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 de
On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
> Alasdair G Kergon wrote:
> > On Fri, Feb 15, 2008 at 01:08:21PM +0100, Andi Kleen wrote:
> >> Implement barrier support for single device DM devices
> >
> > Thanks. We've got some (more-invasive) dm patches in the works that
> >
> 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 04:07:54PM +0300, Michael Tokarev wrote:
> Alasdair G Kergon wrote:
> > On Fri, Feb 15, 2008 at 01:08:21PM +0100, Andi Kleen wrote:
> >> Implement barrier support for single device DM devices
> >
> > Thanks. We've got some (more-invasive) dm patches in the works that
> >
Alasdair G Kergon wrote:
> On Fri, Feb 15, 2008 at 01:08:21PM +0100, Andi Kleen wrote:
>> Implement barrier support for single device DM devices
>
> Thanks. We've got some (more-invasive) dm patches in the works that
> attempt to use flushing to emulate barriers where we can't just
> pass them d
On Fri, Feb 15, 2008 at 01:08:21PM +0100, Andi Kleen wrote:
> Implement barrier support for single device DM devices
Thanks. We've got some (more-invasive) dm patches in the works that
attempt to use flushing to emulate barriers where we can't just
pass them down like that.
Alasdair
--
[EMAIL
Implement barrier support for single device DM devices
This patch implements barrier support in DM for the common case of dm linear
just remapping a single underlying device. In this case we can safely
pass the barrier through because there can be no reordering between
devices.
Signed-off-by: And
23 matches
Mail list logo
