From: Walker, Benjamin <benjamin.walker at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] Change in ...spdk[master]: Initial checkin of the multipath vbdev driver.
Date: Fri, 15 Feb 2019 21:33:58 +0000 [thread overview]
Message-ID: <965f7f6ff56430f4f255bbb7e6916e2c1b4cd154.camel@intel.com> (raw)
In-Reply-To: CANvN+emzBob_pOF5+8QiC4kRo2k20QhKoFcuQ5_vL8+BVVbH1Q@mail.gmail.com
[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]
On Fri, 2019-02-15 at 19:48 +0300, Andrey Kuzmin wrote:
> Ben,
>
> you had indicated that you'd like to have a discussion of the multipath
> driver. Let me know what you think.
I haven't had a chance to through the actual implementation of the patch, but
multipathing in general is certainly of interest and warrants inclusion in SPDK.
I'd love to move ahead on this.
The big challenge is figuring out the best place to implement it. There are at
least 3 different options that I see.
1) Implement it as a bdev module. When the module gets a claim callback, it
checks to see if the new bdev is simply a different path to an existing bdev
(using some mechanism that isn't defined yet?) and then claims them both and
exposes a single bdev to the upper layer.
2) Implement it in the generic bdev code so that each individual bdev module can
call some function to add additional paths to a given bdev.
3) Implement it inside the nvme driver. There are a number of really cool
features for multipathing in NVMe (ANA and such) that don't translate well to a
generic bdev. The only way to take advantage of some of these might be to add
support directly into the nvme driver.
It could be that we end up doing a combination of 1 or 2 with number 3 as well.
I'd love some other opinions here from interested parties.
>
> Thanks,
> Andrey
>
> On Fri, Feb 1, 2019, 21:12 Andrey Kuzmin <akuzmin(a)jetstreamsoft.com wrote:
>
> > I will appreciate an input on if the bdev-level multipathing is of
> > general interest and is worth inclusion. On positive determination I
> > can find time to rebase and resubmit.
> >
> > Notice also that, in this case, decoupling open in write mode from
> > claims patch (https://review.gerrithub.io/c/spdk/spdk/+/422177) should
> > be revisited and included, as otherwise implementing multiple paths to
> > the same base bdev as path bdevs is rather problematic (as this
> > obviously involves multiple writers).
> >
> > Thanks,
> > Andrey
> >
>
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
next reply other threads:[~2019-02-15 21:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-15 21:33 Walker, Benjamin [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-02-18 14:54 [SPDK] Change in ...spdk[master]: Initial checkin of the multipath vbdev driver Andrey Kuzmin
2019-02-15 16:48 Andrey Kuzmin
2019-02-01 18:12 Andrey Kuzmin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=965f7f6ff56430f4f255bbb7e6916e2c1b4cd154.camel@intel.com \
--to=spdk@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox