linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sagi@grimberg.me (Sagi Grimberg)
Subject: [PATCH 0/3] Provide more fine grained control over multipathing
Date: Mon, 4 Jun 2018 14:46:47 +0300	[thread overview]
Message-ID: <29bfbc6c-861d-0348-2f8b-e803acad43ea@grimberg.me> (raw)
In-Reply-To: <20180603160626.GA4361@redhat.com>

[so much for putting out flames... :/]

> This projecting onto me that I've not been keeping the conversation
> technical is in itself hostile.  Sure I get frustrated and lash out (as
> I'm _sure_ you'll feel in this reply)

You're right, I do feel this is lashing out. And I don't appreciate it.
Please stop it. We're not going to make progress otherwise.

>> Can you (or others) please try and articulate why a "fine grained"
>> multipathing is an absolute must? At the moment, I just don't
>> understand.
> 
> Already made the point multiple times in this thread [3][4][5][1].
> Hint: it is about the users who have long-standing expertise and
> automation built around dm-multipath and multipath-tools.  BUT those
> same users may need/want to simultaneously use native NVMe multipath on
> the same host.  Dismissing this point or acting like I haven't
> articulated it just illustrates to me continuing this conversation is
> not going to be fruitful.

The vast majority of the points are about the fact that people still
need to be able to use multipath-tools, which they still can today.
Personally, I question the existence of this user base you are referring
to which would want to maintain both dm-multipath and nvme personalities 
at the same time on the same host. But I do want us to make progress, so
I will have take this need as a given.

I agree with Christoph that changing personality on the fly is going to
be painful. This opt-in will need to be one-host at connect time. For
that, we will probably need to also expose an argument in nvme-cli too.
Changing the mpath personality will need to involve disconnecting the
controller and connecting again with the argument toggled. I think this
is the only sane way to do this.

Another path we can make progress in is user visibility. We have
topology in place and you mentioned primary path (which we could
probably add). What else do you need for multipath-tools to support
nvme?

  reply	other threads:[~2018-06-04 11:46 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-25 12:53 [PATCH 0/3] Provide more fine grained control over multipathing Johannes Thumshirn
2018-05-25 12:53 ` [PATCH 1/3] nvme: provide a way to disable nvme mpath per subsystem Johannes Thumshirn
2018-05-25 13:47   ` Mike Snitzer
2018-05-31  8:17   ` Sagi Grimberg
2018-05-25 12:53 ` [PATCH 2/3] nvme multipath: added SUBSYS_ATTR_RW Johannes Thumshirn
2018-05-25 12:53 ` [PATCH 3/3] nvme multipath: add dev_attr_mpath_personality Johannes Thumshirn
2018-05-25 13:05 ` [PATCH 0/3] Provide more fine grained control over multipathing Christoph Hellwig
2018-05-25 13:58   ` Mike Snitzer
2018-05-25 14:12     ` Christoph Hellwig
2018-05-25 14:50       ` Mike Snitzer
2018-05-29  1:19         ` Martin K. Petersen
2018-05-29  3:02           ` Mike Snitzer
2018-05-29  7:18             ` Hannes Reinecke
2018-05-29  7:22             ` Johannes Thumshirn
2018-05-29  8:09               ` Christoph Hellwig
2018-05-29  9:54                 ` Mike Snitzer
2018-05-29 23:27                 ` Mike Snitzer
2018-05-30 19:05                   ` Jens Axboe
2018-05-30 19:59                     ` Mike Snitzer
2018-06-04  6:19                     ` Hannes Reinecke
2018-06-04  7:18                       ` Johannes Thumshirn
2018-06-04 12:59                         ` Christoph Hellwig
2018-06-04 13:27                           ` Mike Snitzer
2018-05-31  2:42               ` Ming Lei
2018-05-30 21:20     ` Sagi Grimberg
2018-05-30 22:02       ` Mike Snitzer
2018-05-31  8:37         ` Sagi Grimberg
2018-05-31 12:37           ` Mike Snitzer
2018-05-31 16:34             ` Christoph Hellwig
2018-06-01  4:11               ` Mike Snitzer
2018-05-31 16:36           ` Christoph Hellwig
2018-05-31 16:33         ` Christoph Hellwig
2018-05-31 18:17           ` Mike Snitzer
2018-06-01  2:40             ` Martin K. Petersen
2018-06-01  4:24               ` Mike Snitzer
2018-06-01 14:09                 ` Martin K. Petersen
2018-06-01 15:21                   ` Mike Snitzer
2018-06-03 11:00                 ` Sagi Grimberg
2018-06-03 16:06                   ` Mike Snitzer
2018-06-04 11:46                     ` Sagi Grimberg [this message]
2018-06-04 12:48                       ` Johannes Thumshirn
2018-05-30 22:44       ` Mike Snitzer
2018-05-31  8:51         ` Sagi Grimberg
2018-05-31 12:41           ` Mike Snitzer
2018-06-04 21:58       ` Roland Dreier
2018-06-05  4:42         ` Christoph Hellwig
2018-06-05 22:57           ` Roland Dreier
2018-06-06  9:51             ` Christoph Hellwig
2018-06-06  9:32           ` Sagi Grimberg
2018-06-06  9:50             ` Christoph Hellwig
2018-05-25 14:22   ` Johannes Thumshirn
2018-05-25 14:30     ` Christoph Hellwig

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=29bfbc6c-861d-0348-2f8b-e803acad43ea@grimberg.me \
    --to=sagi@grimberg.me \
    /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;
as well as URLs for NNTP newsgroup(s).