On Wed, Sep 01 2010 at 8:12am -0400, Mikulas Patocka <mpatocka@xxxxxxxxxx> 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
