All of lore.kernel.org
 help / color / mirror / Atom feed
From: kbusch@kernel.org (Keith Busch)
Subject: [PATCH RFC] nvme: Common subsys and controller instances IDA
Date: Fri, 24 May 2019 17:30:14 -0600	[thread overview]
Message-ID: <20190524233014.GC17343@localhost.localdomain> (raw)
In-Reply-To: <1825f9cf-fa66-4232-12f9-3e27c73a7395@grimberg.me>

On Fri, May 24, 2019@04:23:36PM -0700, Sagi Grimberg wrote:
> 
> > Sagi,
> > 
> > my original patch showed the namespaces and not the mpath device since I
> > developed it in non mpath environment.
> > 
> > Afterwards, Keith asked me to test it on mpath env and I changed my V1
> > to show the mpath device (in case of mpath configuration) and "IO-ble"
> > block device in case of non mpath configuration.
> > 
> > I thought that this was Keith intention but afterwards we agreed to
> > print the "IO-ble" namespace in all the cases (Also Christoph agreed on
> > that).
> 
> What's IO-ble?

Just means "not hidden".
 
> > So I'll update the patchset to show always the "IO-ble" namespace and
> > not mpath slaves that a user can't do anything interested with them.
> 
> But a namespace in a multipath environment is not associated with a
> controller. I don;t understand how you can display that without
> confusing the user even more.
>
> Unless they are not nested under controllers but under subsystems, that
> is fine, and aligned with the spec.

The virtual device "head" is associated with a subsystem where its
device names comes from, but that head has namespace paths, which are
controllers, and this is just showing that topology.

It would not make sense to nest the block device names under the
subsystem because the substem may have many paths/controllers, but the
namespaces are accessible only under a subset of those paths.

  reply	other threads:[~2019-05-24 23:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15 21:33 [PATCH RFC] nvme: Common subsys and controller instances IDA Keith Busch
2019-05-16  6:46 ` Christoph Hellwig
2019-05-16  7:03   ` Hannes Reinecke
2019-05-16 14:44     ` Keith Busch
2019-05-16 14:51       ` Christoph Hellwig
2019-05-16 14:58       ` Martin K. Petersen
2019-05-21  9:54         ` Max Gurtovoy
2019-05-21 14:35           ` Keith Busch
2019-05-21 14:51             ` Max Gurtovoy
2019-05-21 14:58               ` Keith Busch
2019-05-24  8:03             ` Sagi Grimberg
2019-05-24 14:07               ` Keith Busch
2019-05-24 16:17                 ` Sagi Grimberg
2019-05-24 19:14                   ` Max Gurtovoy
2019-05-24 23:23                     ` Sagi Grimberg
2019-05-24 23:30                       ` Keith Busch [this message]
2019-05-16 14:40   ` Keith Busch
2019-05-16 14:57     ` Keith Busch

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=20190524233014.GC17343@localhost.localdomain \
    --to=kbusch@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.