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

[Mikulas Patocka]

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.

Mikulas

> 	/*
> 	 * If we're suspended or the thread is processing barriers
> 	 * we have to queue this io for later.
> 	 */
> 
> Tejun also shared the following:
> 
> "bio based implementation also uses dm_wait_for_completion() and
> DMF_QUEUE_IO_TO_THREAD to plug all the follow up bio's while flush is in
> progress, which sucks for throughput but successfully avoids starvation."
> 
> here:
> https://www.redhat.com/archives/dm-devel/2010-August/msg00174.html
>