[dm-devel] [PATCH UPDATED 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
Mike Snitzer
snitzer at redhat.com
Wed Sep 1 15:20:54 UTC 2010
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:
/*
* 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
More information about the dm-devel
mailing list