From: Nilay Shroff <nilay@linux.ibm.com>
To: Keith Busch <kbusch@kernel.org>
Cc: dwagner@suse.de, linux-nvme@lists.infradead.org, hch@lst.de,
sagi@grimberg.me, gjoyce@ibm.com, msmurthy@imap.linux.ibm.com,
axboe@fb.com
Subject: Re: [PATCH nvme-cli] nvme: warn about attaching a namespace to unknown controller
Date: Sat, 22 Jun 2024 16:05:01 +0530 [thread overview]
Message-ID: <702e63dd-8fe6-4c23-89fd-7075573bb445@linux.ibm.com> (raw)
In-Reply-To: <ZnWXc8wrNR_ijnTH@kbusch-mbp>
On 6/21/24 20:38, Keith Busch wrote:
> On Thu, Jun 20, 2024 at 06:25:45PM +0530, Nilay Shroff wrote:
>> Sometime it's possible for a multi-controller NVMe disk to have only
>> one of its controller discovered by the kernel. And if this happens
>> then it's also possible for a user to create and then attach a namespace
>> to a controller which has not been discovered by the kernel. In such a
>> case the attached namespace can't be used for IO because there's no path
>> to reach such namespace from the kernel.
>
> Isn't that a pretty normal thing to do, though? Like for an sriov
> situation, a primary controller attaches namespaces to secondaries, but
> not to itself.
Yes correct, but in case of sriov, AFAIK, the "nvme list-secondary ...." shall
not list any secondary controller unless the secondary controller's corresponding
VF is enabled (i.e. /sys/class/nvme/nvmeX/device/sriov_numvfs set to at least the
secondary controller's VF number).
So it means that before attaching namespace to secondaries, user would first set
sriov_numvfs. Setting numvfs would then enable the kernel to discover all secondary
controllers.
However, in the proposed patch we're trying to address a case where "nvme list-ctrl ..."
shows multiple controller entries however only one of those controllers is discovered
by kernel. All controllers shown in the output of "nvme list-ctrl ..." are physical
controllers on the nvme disk. In this case attaching a namespace to any of the
undiscovered controller has a side effect due which the namespace rendered unusable.
This patch tries to address this issue by showing a WARNING to the user and optionally
allowing user to cancel the attach operation. However if user still prefers to go
ahead without cancelling the attach operation then nvme-cli would execute this command
as usual.
For sriov use case, as secondary controllers have been already discovered by kernel
before we attach namespace to secondaries, it doesn't have any side effect.
Thanks,
--Nilay
next prev parent reply other threads:[~2024-06-22 10:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 12:55 [PATCH nvme-cli] nvme: warn about attaching a namespace to unknown controller Nilay Shroff
2024-06-21 15:08 ` Keith Busch
2024-06-22 10:35 ` Nilay Shroff [this message]
2024-06-24 19:32 ` Keith Busch
2024-06-25 6:23 ` Nilay Shroff
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=702e63dd-8fe6-4c23-89fd-7075573bb445@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=axboe@fb.com \
--cc=dwagner@suse.de \
--cc=gjoyce@ibm.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=msmurthy@imap.linux.ibm.com \
--cc=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