On Wed, Feb 15 2017 at 9:56am -0500,
Christoph Hellwig wrote:
> On Tue, Feb 14, 2017 at 04:19:13PM -0500, Keith Busch wrote:
> > These devices are mulitpath capable, and have been able to stack with
> > dm-mpath since kernel 4.2.
>
> Can we make this conditional on something? I have native NVM
On 02/15/17 18:53, Mike Snitzer wrote:
Nobody has interest in Linux multipathing becoming fragmented.
If every transport implemented their own multipathing the end-user would
be amazingly screwed trying to keep track of all the
quirks/configuration/management of each.
Not saying multipath-tools
On Thu, Feb 16 2017 at 12:00am -0500,
Bart Van Assche wrote:
> On 02/15/17 18:53, Mike Snitzer wrote:
> >Nobody has interest in Linux multipathing becoming fragmented.
> >
> >If every transport implemented their own multipathing the end-user would
> >be amazingly screwed trying to keep track of a
On Wed, Feb 15, 2017 at 09:53:57PM -0500, Mike Snitzer wrote:
> going to LSF/MM?). Yet you're expecting to just drop it into the tree
> without a care in the world about the implications.
I am planning to post it for comments, and then plan to "drop it in the
tree" exactly because I think of the
On Thu, Feb 16 2017 at 9:26am -0500,
Christoph Hellwig wrote:
> On Wed, Feb 15, 2017 at 09:53:57PM -0500, Mike Snitzer wrote:
> > going to LSF/MM?). Yet you're expecting to just drop it into the tree
> > without a care in the world about the implications.
>
> I am planning to post it for comme
On Thu, Feb 16, 2017 at 10:13:37AM -0500, Mike Snitzer wrote:
> On Thu, Feb 16 2017 at 9:26am -0500,
> Christoph Hellwig wrote:
>
> > just a little new code in the block layer, and a move of the path
> > selectors from dm to the block layer. I would not call this
> > fragmentation.
>
> I'm fine
On Thu, 2017-02-16 at 12:38 -0500, Keith Busch wrote:
> Maybe I'm not seeing the bigger picture. Is there some part to multipath
> that the kernel is not in a better position to handle?
Does this mean that the code to parse /etc/multipath.conf will be moved into
the kernel? Or will we lose the abi
On Thu, Feb 16, 2017 at 05:37:41PM +, Bart Van Assche wrote:
> On Thu, 2017-02-16 at 12:38 -0500, Keith Busch wrote:
> > Maybe I'm not seeing the bigger picture. Is there some part to multipath
> > that the kernel is not in a better position to handle?
>
> Does this mean that the code to parse
I'm fine with the path selectors getting moved out; maybe it'll
encourage new path selectors to be developed.
But there will need to be some userspace interface stood up to support
your native NVMe multipathing (you may not think it needed but think in
time there will be a need to configure _so
On Thu, Feb 16 2017 at 1:07pm -0500,
Keith Busch wrote:
> On Thu, Feb 16, 2017 at 05:37:41PM +, Bart Van Assche wrote:
> > On Thu, 2017-02-16 at 12:38 -0500, Keith Busch wrote:
> > > Maybe I'm not seeing the bigger picture. Is there some part to multipath
> > > that the kernel is not in a be
On Thu, 2017-02-16 at 07:37 -0500, Mike Snitzer wrote:
> Weird. I did push back on those changes initially (just felt like
> churn) but I ultimately did take them:
>
> $ git log --oneline --author=bart drivers/md/dm-mpath.c
> 6599c84 dm mpath: do not modify *__clone if blk_mq_alloc_request() fail
On Thu, Feb 16 2017 at 2:46pm -0500,
Bart Van Assche wrote:
> On Thu, 2017-02-16 at 07:37 -0500, Mike Snitzer wrote:
> > Weird. I did push back on those changes initially (just felt like
> > churn) but I ultimately did take them:
> >
> > $ git log --oneline --author=bart drivers/md/dm-mpath.c
On Thu, Feb 16, 2017 at 01:21:29PM -0500, Mike Snitzer wrote:
> Then undeprecate them. Decisions like marking a path checker deprecated
> were _not_ made with NVMe in mind. They must predate NVMe.
>
> multipath-tools has tables that specify all the defaults for a given
> target backend. NVMe wi
On Thu, 2017-02-16 at 15:23 -0500, Mike Snitzer wrote:
> Or you can wait to rebase on v4.11-rc1 in ~2 weeks.
Hello Mike,
I will wait until v4.11-rc1 has been released.
Thanks,
Bart.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Thu, Feb 16, 2017 at 08:05:36PM +0200, Sagi Grimberg wrote:
> I guess one config option that we'd need is multibus vs. failover
> which are used per use-case.
Which fundamentally is a property of the target first, and it should
tell us that. There might be the occasional need for an override,
On Thu, Feb 16, 2017 at 01:21:29PM -0500, Mike Snitzer wrote:
> multipath-tools has tables that specify all the defaults for a given
> target backend. NVMe will just be yet another.
No, if we get things right it won't. ALUA already got rid of most
of the parameter people would have to set under
On Thu, Feb 16, 2017 at 10:13:37AM -0500, Mike Snitzer wrote:
> Not following what you're saying Keith did. Please feel free to
> clarify.
Keith demonstrated what it takes to support NVMe with dm. He also
gave a couple presentations on it in addition to various ptches on
the list.
> The middle
On Fri, Feb 17 2017 at 4:33am -0500,
Christoph Hellwig wrote:
> On Thu, Feb 16, 2017 at 10:13:37AM -0500, Mike Snitzer wrote:
> > Not following what you're saying Keith did. Please feel free to
> > clarify.
>
> Keith demonstrated what it takes to support NVMe with dm. He also
> gave a couple
On Fri, Feb 17 2017 at 4:05am -0500,
Christoph Hellwig wrote:
> On Thu, Feb 16, 2017 at 08:05:36PM +0200, Sagi Grimberg wrote:
> > I guess one config option that we'd need is multibus vs. failover
> > which are used per use-case.
>
> Which fundamentally is a property of the target first, and it
On Fri, Feb 17 2017 at 4:04am -0500,
h...@infradead.org wrote:
> On Thu, Feb 16, 2017 at 01:21:29PM -0500, Mike Snitzer wrote:
> > multipath-tools has tables that specify all the defaults for a given
> > target backend. NVMe will just be yet another.
>
> No, if we get things right it won't. A
20 matches
Mail list logo
