[dm-devel] [PATCH UPDATED 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm

[Mike Snitzer]

On Wed, Sep 01 2010 at 11:35am -0400,
Mikulas Patocka <mpatocka at redhat.com> wrote:

> 
> 
> On Wed, 1 Sep 2010, Mike Snitzer wrote:
> 
> > On Wed, Sep 01 2010 at  8:12am -0400,
> > Mikulas Patocka <mpatocka at redhat.com> wrote:
> > 
> > > On Wed, 1 Sep 2010, Tejun Heo wrote:
> > > 
> > > > Hello,
> > > > 
> > > > On 09/01/2010 12:31 PM, Mikulas Patocka wrote:
> > > > > My recommended approach to this (on non-request-based dm) is to simply let 
> > > > > the current barrier infrastructure be as it is --- you don't need to 
> > > > > change it now, you can simply map FUA write to barrier write and FLUSH to 
> > > > > zero-data barrier --- and it won't cause any data corruption. It will just 
> > > > > force unneeded I/O queue draining.
> > > > > 
> > > > > Once FLUSH+FUA interface is finalized and committed upstream, we can 
> > > > > remove that I/O queue draining from dm to improve performance.
> > > > 
> > > > Unfortunately, it doesn't work that way.  The current dm
> > > > implementation depends on block layer holding the queue while a
> > > > barrier sequence is in progress which the new implementation doesn't
> > > > do anymore (the whole point of this conversion BTW).
> > > 
> > > That may be true for request-based dm (I don't know).
> > > 
> > > But bio-based dm doesn't depend on it, I wrote it and I didn't rely on 
> > > that.
> > 
> > Mikulas,
> > 
> > Current bio-based barrier support also defers IO if a flush is in
> > progress.  See _dm_request:
> 
> I know. But it doesn't hurt with flush/fua requests. It just lowers 
> performance (it defers i/os when it doesn't have to) but doesn't damage 
> data.
> 
> So I think that we can let it be this way until flush/fua patch is 
> finalized.

Neither Tejun nor I see the point in waiting when we have a window of
time to address the issues now.  We want DM to realize the benefit
associated with the kernel-wide FLUSH+FUA conversion too.

You're not explaining your reluctance to tackle review of this DM
FLUSH+FUA conversion.  Converting DM can (and already has) exposed some
shortcomings in the the kernel-wide FLUSH+FUA conversion.

We can't afford for these kernel-wide changes to go in and have DM left
trying to fix some fundamental kernel issue outside of DM after the
fact.

So why wait?  This debate has distracted you from just reviewing the
code.  The bio-based DM changes are fairly straight-forward.

Mike