lkml.org 
[lkml]   [2011]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Block regression since 3.1-rc3
    From
    2011/10/9 Mike Snitzer <snitzer@redhat.com>:
    > On Sat, Oct 08 2011 at  7:02am -0400,
    > Shaohua Li <shli@kernel.org> wrote:
    >
    >> Looks the dm request based flush logic is broken.
    >>
    >> saved_make_request_fn
    >>   __make_request
    >>     blk_insert_flush
    >> but blk_insert_flush doesn't put the original request to list, instead, the
    >> q->flush_rq is in list.
    >> then
    >> dm_request_fn
    >>   blk_peek_request
    >>     dm_prep_fn
    >>       clone_rq
    >>   map_request
    >>     blk_insert_cloned_request
    >> so q->flush_rq is cloned, and get dispatched. but we can't clone q->flush_rq
    >> and use it to do flush. map_request even could assign a different blockdev to
    >> the cloned request.
    >
    > You haven't explained why cloning q->flush_rq is broken.  What is the
    > problem with map_request changing the blockdev?  For the purposes of
    > request-based DM the flush machinery has already managed the processing
    > of the flush at the higher level request_queue.
    hmm, looks I overlook the issue. cloned flush_rq has some problems but can
    be fixed.
    1. it doesn't set requet->bio, request->bio_tail
    2. REQ_CLONE_MASK should set REQ_FLUSH_SEQ

    > By the time request-based DM is cloning a flush request it really has no
    > need to reenter the flush machinery (even though Tejun wants it to --
    > but in practice it doesn't buy us anything because we never stack
    > request-based DM at the moment.  Instead it showcases how brittle this
    > path is).
    if there is no benefit, we'd better not clone a flush request. Clearing flush
    bit and set it to cloned request is more clean and avoid unnecessary
    overhead/complexity.

    Thanks,
    Shaohua
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-10-09 06:35    [W:0.026 / U:0.136 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site