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

[Mike Snitzer <snitzer@redhat.com>]

On Wed, Sep 01 2010 at  8:12am -0400,
Mikulas Patocka <mpatocka@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:

	/*
	 * 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