Messages in this thread | | | From | Jeff Moyer <> | Subject | Re: [patch] blk-flush: fix flush policy calculation | Date | Tue, 09 Aug 2011 13:29:02 -0400 |
| |
Vivek Goyal <vgoyal@redhat.com> writes:
> On Tue, Aug 02, 2011 at 03:46:49PM -0400, Jeff Moyer wrote: >> Vivek Goyal <vgoyal@redhat.com> writes: >> >> >> In testing, I did this: >> >> >> >> @@ -1817,6 +1817,14 @@ int blk_insert_cloned_request(struct >> >> request_queue *q, struct request *rq) >> >> return -EIO; >> >> #endif >> >> >> >> + if ((rq->cmd_flags & (REQ_FLUSH|REQ_FUA)) && !q->flush_flags) { >> >> + rq->cmd_flags &= ~(REQ_FLUSH|REQ_FUA); >> >> + if (!blk_rq_bytes(rq)) { >> >> + blk_end_request(rq, 0, 0); >> >> + return 0; >> >> + } >> >> + } >> >> + >> > >> > Will it make more sense to take care resetting flush/fua flags in >> > blk_insert_flush() >> >> Yes, that's much cleaner. >> >> > and also the part which will end the request if request is empty. >> >> Mmm-hmm. >> >> I tried this, and it blew up in my face. ;-) Cloned requests from >> device-mapper-land have rq->end_io filled in, which causes >> blk_insert_flush to BUG here: >> >> BUG_ON(rq->end_io); > > So how does it work when underlying device supports FLUSH/FUA? That means > that dm-multipath requets never go through flush machinery? So if a
Yes, they do. They go through it *above* dm-multipath, and dm-multipath just hands the requests down to the device via whatever path it selects.
Cheers, Jeff
| |