On Tue, Oct 08 2013 at 6:37am -0400, Akira Hayakawa <ruby.wktk@xxxxxxxxx> wrote: > Christoph, > > > You can detect O_DIRECT writes by second guession a special combination > > of REQ_ flags only used there, as cfg tries to treat it special: > > > > #define WRITE_SYNC (WRITE | REQ_SYNC | REQ_NOIDLE) > > #define WRITE_ODIRECT (WRITE | REQ_SYNC) > > > > the lack of REQ_NOIDLE when REQ_SYNC is set gives it away. Not related > > to the FLUSH or FUA flags in any way, though. > Thanks. > But, our problem is to detect the bio may or may not be deferred. > The flag REQ_NOIDLE is the one? > > > Akira, can you explain the workloads where your delay of FLUSH or FUA > > requests helps you in any way? I very much agree with Dave's reasoning, > > but if you found workloads where your hack helps we should make sure we > > fix them at the place where they are issued. > One of the examples is a fileserver accessed by multiple users. > A barrier is submitted when a user closes a file for example. > > As I said in my previous post > https://lkml.org/lkml/2013/10/4/186 > writeboost has RAM buffer and we want one to be > fulfilled with writes and then flushed to the cache device > that takes all the barriers away with the completion. > In that case we pay the minimum penalty for the barriers. > Interestingly, writeboost is happy with a lot of writes. > > By deferring these barriers (FLUSH and FUA) > multiple barriers are likely to be merged on a RAM buffer > and then processed by replacing with only one FLUSH. > > Merging the barriers and replacing it with a single FLUSH > by accepting a lot of writes > is the reason for deferring barriers in writeboost. > If you want to know further I recommend you to > look at the source code to see > how queue_barrier_io() is used and > how the barriers are kidnapped in queue_flushing(). AFAICT, this is an unfortunate hack resulting from dm-writeboost being a bio-based DM target. The block layer already has support for FLUSH merging, see commit ae1b1539622fb4 ("block: reimplement FLUSH/FUA to support merge") -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
