[PATCH 00/13] request-based dm-multipath - Kernel

This is a discussion on [PATCH 00/13] request-based dm-multipath - Kernel ; On Fri, Sep 12, 2008 at 8:16 PM, Kiyoshi Ueda wrote: > This patch enables request-based dm. > > o Request-based dm and bio-based dm coexist, since there are > some target drivers which are more fitting to bio-based dm. ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 26 of 26

Thread: [PATCH 00/13] request-based dm-multipath

  1. Re: [dm-devel] [PATCH 11/13] dm: enable request-based dm

    On Fri, Sep 12, 2008 at 8:16 PM, Kiyoshi Ueda wrote:
    > This patch enables request-based dm.
    >
    > o Request-based dm and bio-based dm coexist, since there are
    > some target drivers which are more fitting to bio-based dm.
    > Also, there are other bio-based devices in the kernel
    > (e.g. md, loop).
    > Since bio-based device can't receive struct request,
    > there are some limitations on device stacking between
    > bio-based and request-based.
    >
    > type of underlying device
    > bio-based requeset-based
    > ----------------------------------------------
    > bio-based OK OK
    > request-based NG OK
    >


    So will some configurations would become impossible, if a target is
    made request-based and bio-based one is removed. Hope both
    types of targets would co-exist and would be selectable for sometime.

    > The device type is recognized by the queue flag in the kernel,
    > so dm follows that.
    >
    > o The type of a dm device is decided at the first table loading time.
    > Until then, mempool creations are deferred, since mempools for
    > request-based dm are different from those for bio-based dm.
    > Once the type of a dm device is decided, the type can't be changed.
    >
    > o Currently, request-based dm supports only tables that have a single
    > target.


    Barrier support should be straight forward?

    Thanks
    Nikanth Karthikesan
    --
    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/

  2. Re: [dm-devel] [PATCH 13/13] dm-mpath: convert to request-based

    On Fri, Sep 12, 2008 at 8:17 PM, Kiyoshi Ueda wrote:
    > This patch converts dm-multipath target to request-based from bio-based.
    >


    Can we keep both the bio-based as well as request-based dm-multipath?

    Thanks
    Nikanth Karthikesan
    --
    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/

  3. Re: [dm-devel] [PATCH 11/13] dm: enable request-based dm

    Hi Nikanth,

    On Fri, 24 Oct 2008 13:22:46 +0530, "Nikanth K" wrote:
    > On Fri, Sep 12, 2008 at 8:16 PM, Kiyoshi Ueda wrote:
    > > This patch enables request-based dm.
    > >
    > > o Request-based dm and bio-based dm coexist, since there are
    > > some target drivers which are more fitting to bio-based dm.
    > > Also, there are other bio-based devices in the kernel
    > > (e.g. md, loop).
    > > Since bio-based device can't receive struct request,
    > > there are some limitations on device stacking between
    > > bio-based and request-based.
    > >
    > > type of underlying device
    > > bio-based requeset-based
    > > ----------------------------------------------
    > > bio-based OK OK
    > > request-based NG OK
    > >

    >
    > So will some configurations would become impossible, if a target is
    > made request-based and bio-based one is removed. Hope both
    > types of targets would co-exist and would be selectable for sometime.


    If the target is used anywhere in the device stack (e.g. linear),
    both types of the target are needed, and that is possible.

    As for multipath, see my another reply to your comment for PATCH 13.

    Thanks,
    Kiyoshi Ueda
    --
    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/

  4. Re: [dm-devel] [PATCH 13/13] dm-mpath: convert to request-based

    Hi Nikanth,

    On Fri, 24 Oct 2008 13:25:33 +0530, "Nikanth K" wrote:
    > On Fri, Sep 12, 2008 at 8:17 PM, Kiyoshi Ueda wrote:
    > > This patch converts dm-multipath target to request-based from bio-based.

    >
    > Can we keep both the bio-based as well as request-based dm-multipath?


    Why do you want to keep bio-based dm-multipath?
    In the realistic environment, dm-multipath is usually the bottom
    of the stacking devices. So I think existing working configurations
    are still possible with request-based dm-multipath.

    If we keep both types of multipath targets, maintenance cost would
    be doubled and additional user interface might be needed to specify
    which type is used. I can't see any major benefit worth paying
    the cost of keeping bio-based dm-multipath.

    I know dm developers sometimes use linear/error maps under multipath
    just for testing purpose. If that is your requirement, I can make
    request-based targets for linear and error (e.g. named like linear_rq
    and error_rq).

    Thanks,
    Kiyoshi Ueda
    --
    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/

  5. Re: [dm-devel] [PATCH 10/13] dm: add core functions for request-based dm

    Hi Nikanth,

    On Fri, 24 Oct 2008 13:14:50 +0530, "Nikanth K" wrote:
    > On Fri, Sep 12, 2008 at 8:16 PM, Kiyoshi Ueda wrote:
    >
    >
    > > +static int dm_make_request(struct request_queue *q, struct bio *bio)
    > > +{
    > > + struct mapped_device *md = (struct mapped_device *)q->queuedata;
    > > +
    > > + if (unlikely(bio_barrier(bio))) {
    > > + bio_endio(bio, -EOPNOTSUPP);
    > > + return 0;
    > > + }
    > > +

    >
    >
    > Why not add barrier support in the beginning itself, so that targets
    > can be developed with barriers in mind? At least can we make the target
    > to return error, instead of the core?


    Currently, there is no barrier support in dm, not only request-based.
    Barrier support is a different feature in the next step, I think.

    As you noticed in the PATCH#11, current request-based dm has
    the limitation that multiple targets are not supported, so it may
    look barrier support in request-based dm is easy.
    But we may be able to remove the limitation in the future, so
    depending on it is not a good idea.

    Thanks,
    Kiyoshi Ueda
    --
    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/

  6. Re: [dm-devel] [PATCH 10/13] dm: add core functions for request-based dm

    Hi Nikanth,

    Nikanth Karthikesan wrote:
    > Hi Kiyoshi
    >
    >>>> On 10/28/2008 at 09:30 PM, Kiyoshi Ueda wrote:

    >> Hi Nikanth,
    >>
    >> On Fri, 24 Oct 2008 13:14:50 +0530, "Nikanth K" wrote:
    >>> On Fri, Sep 12, 2008 at 8:16 PM, Kiyoshi Ueda wrote:
    >>>
    >>>
    >>>> +static int dm_make_request(struct request_queue *q, struct bio *bio)
    >>>> +{
    >>>> + struct mapped_device *md = (struct mapped_device *)q->queuedata;
    >>>> +
    >>>> + if (unlikely(bio_barrier(bio))) {
    >>>> + bio_endio(bio, -EOPNOTSUPP);
    >>>> + return 0;
    >>>> + }
    >>>> +
    >>>
    >>>
    >>> Why not add barrier support in the beginning itself, so that targets
    >>> can be developed with barriers in mind? At least can we make the target
    >>> to return error, instead of the core?

    >> Currently, there is no barrier support in dm, not only request-based.
    >> Barrier support is a different feature in the next step, I think.

    >
    > But there are some works in that direction to add support for barriers in dm.
    > That is why I think building request-based dm with barriers from the
    > ground up might be a good idea.


    I agree, if I or other people have a time to implement barrier support
    for request-based dm.
    But I think the some works you mentioned above are:
    - Andi Kleen: barrier support for linear (single device)
    - Milan Broz: full barrier support in dm core (no target patch)
    so there is no barrier support work for dm-multipath yet.

    Current request-based target is only dm-multipath, so we won't have
    any feature regression even if request-based dm-multipath gets in.
    And I don't have much time to implement barrier support for
    request-based dm-multipath now, so I'd like to consider it as
    the next step.

    Thanks,
    Kiyoshi Ueda
    --
    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/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2