From: John Meneghini <jmeneghi@redhat.com>
To: Maurizio Lombardi <mlombard@arkamax.eu>,
Keith Busch <kbusch@kernel.org>,
Maurizio Lombardi <mlombard@redhat.com>
Cc: hch@lst.de, hare@suse.de, chaitanyak@nvidia.com,
bvanassche@acm.org, linux-scsi@vger.kernel.org,
linux-nvme@lists.infradead.org,
James.Bottomley@hansenpartnership.com, emilne@redhat.com,
bgurney@redhat.com
Subject: Re: [PATCH V3 0/3] Ensure ordered namespace registration during async scan
Date: Thu, 26 Feb 2026 11:35:15 -0500 [thread overview]
Message-ID: <e43b914c-2ca5-455e-b0fe-3ce2eb0c64bd@redhat.com> (raw)
In-Reply-To: <DGOQMFJJ6K5P.3KLF45WQT2SAS@arkamax.eu>
On 2/26/26 3:07 AM, Maurizio Lombardi wrote:
> On Wed Feb 25, 2026 at 10:41 PM CET, Keith Busch wrote:
>> On Wed, Feb 25, 2026 at 05:12:00PM +0100, Maurizio Lombardi wrote:
>>> The NVMe fully asynchronous namespace scanning introduced in
>>> commit 4e893ca81170 ("nvme-core: scan namespaces asynchronously")
>>> significantly improved discovery times. However, it also introduced
>>> non-deterministic ordering for namespace registration.
>>>
>>> While kernel device names (/dev/nvmeXnY) are not guaranteed to be stable
>>> across reboots, this unpredictable ordering has caused considerable user
>>> confusion and has been perceived as a regression, leading to multiple bug
>>> reports.
>>
>> The nvme-pci driver also probes the controllers asynchronously, which
>> can also create non-determinisitic names. Is that part not a problem?
>
> Potentially, it is. The difference is that so far no one ever complained
> about it, while with namespace async scanning we immediately received regression
> reports, to the point we had to revert the changes and restore the
> sequential namespaces scan in RHEL.
It's worse than this. Yes, in RHEL we carry out of tree patches to tun off the async scanning with SCSI,
and we reverted this async namespace scanning patch in NVMe.
We had to do this because, as soon as we turned these async scanning mechanisms on, we immediately
received customer escalations. Customer were not able to upgrade their systems. We have customer issues
and complaints open about this and we see this async namespace scanning as a barrier to adoption with NVMEe -
especially with NVME-OF which tends to have many more Namespaces than PCIe.
We've talked about this at LSF/MM - more than once - and several solutions have been proposed in the past,
but nothing ever happened.
And yes, the PCIe async discovery stuff does cause some problems. The difference is: the PCIe bus configuration does
not change nearly as often as, e.g., the nvme namespace configuration in a fabric, so customers don't notice the changing pci ids.
Unless some one is going lots of hot unplugging and plugging with their PCI bus, the PCI ids typically don't change at all.
So from boot to boot, pci id don't usually change. This async namespace scanning causes the namespace ids to change with every reboot, especially on
a system with 100's of nvme-of namespaces.
So, we really need this change, or something like this, to be accepted upstream.
/John
next prev parent reply other threads:[~2026-02-26 16:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 16:12 [PATCH V3 0/3] Ensure ordered namespace registration during async scan Maurizio Lombardi
2026-02-25 16:12 ` [PATCH V3 1/3] lib: Introduce completion chain helper Maurizio Lombardi
2026-02-25 16:12 ` [PATCH V3 2/3] nvme-core: register namespaces in order during async scan Maurizio Lombardi
2026-02-25 21:37 ` kernel test robot
2026-02-25 16:12 ` [PATCH V3 3/3] scsi: Convert async scanning to use the completion chain helper Maurizio Lombardi
2026-02-25 21:41 ` [PATCH V3 0/3] Ensure ordered namespace registration during async scan Keith Busch
2026-02-26 8:07 ` Maurizio Lombardi
2026-02-26 15:09 ` Keith Busch
2026-02-26 16:35 ` John Meneghini [this message]
2026-02-26 18:15 ` Keith Busch
2026-03-02 7:16 ` Hannes Reinecke
2026-03-02 17:12 ` 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=e43b914c-2ca5-455e-b0fe-3ce2eb0c64bd@redhat.com \
--to=jmeneghi@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=bgurney@redhat.com \
--cc=bvanassche@acm.org \
--cc=chaitanyak@nvidia.com \
--cc=emilne@redhat.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mlombard@arkamax.eu \
--cc=mlombard@redhat.com \
/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