Messages in this thread | | | Date | Thu, 6 Sep 2012 14:29:52 -0700 | From | Tejun Heo <> | Subject | Re: [Drbd-dev] FLUSH/FUA documentation & code discrepancy |
| |
Hello,
On Wed, Sep 05, 2012 at 12:07:24PM +0200, Lars Ellenberg wrote: > So reiterating the situation: > > If I'd submit a non-empty bio with FLUSH/FUA set, > on a queue that does support flush, we get to > blk_queue_bio() > if (bio->bi_rw & (REQ_FLUSH | REQ_FUA)) { > spin_lock_irq(q->queue_lock); > where = ELEVATOR_INSERT_FLUSH; > goto get_rq; > > This bio ends up *not* being merged or reordered by the elevator. > (and, by means of flush/fua not by the hardware, either, obviously) > > If the queue does not support it, flags are stripped away in > generic_make_request_checks(), and we will not take that branch > in blk_queue_bio(), but enter the normal elevator code path, > attempting a merge, or doing ELEVATOR_INSERT_SORT.
which is an implementation detail.
> This same bio, happening to be submitted on a different IO stack, > now *is* being reordered in the elevator already, > even before being sent to the hardware.
and this is perfectly fine.
I really don't see what problem you're trying to solve here. The ordering requirement is weak. Certain implementation path uses stronger requirement for convenience / historical reasons. If any change makes sense, it's relaxing the unnecessarily strict ordering if possible.
What actual problem are you seeing?
Thanks.
-- tejun
| |