From: Christoph Hellwig <hch@lst.de>
To: "xiaoke@sangfor.com.cn" <xiaoke@sangfor.com.cn>
Cc: linux-nvme@lists.infradead.org, Christoph Hellwig <hch@lst.de>,
sagi@grimberg.me, axboe@kernel.dk, kbusch@kernel.org
Subject: Re: [PATCH] nvme: don't reject probe due to duplicate IDs for single-ported PCIe devices
Date: Thu, 22 Jan 2026 07:38:57 +0100 [thread overview]
Message-ID: <20260122063857.GA24621@lst.de> (raw)
In-Reply-To: <56389e0f-b0b6-49b1-8de3-d8d18e507189@sangfor.com.cn>
On Tue, Jan 20, 2026 at 05:54:25PM +0800, xiaoke@sangfor.com.cn wrote:
>
> I’d like to discuss whether we should revisit the duplicate-ID check
> for NVMe-oF transports, especially in HA dual-active setups.
>
> In such HA configurations, a single LUN is exposed via multiple subsystems
> (one per storage controller) to provide redundancy. Because it represents
> the same namespace, it usually reports the same UUID/NGUID/EUI64 on all
> paths.
Not in any configuration confirming to the NVMe spec (discounting the
completely broken dispersed namespace feature).
So no, this is exactly what both the spec, and the code try to prevent.
> > + if ((ns->ctrl->ops->flags & NVME_F_FABRICS) || /* !PCIe */
> > + ((ns->ctrl->subsys->cmic & NVME_CTRL_CMIC_MULTI_CTRL) &&
> > + info->is_shared)) {
>
> Concretely, with two subsystems exposing the same LUN in a dual-active
> HA configuration:
There are no logical units or logical unit numbers in NVMe.
prev parent reply other threads:[~2026-01-22 6:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20230713133859epcas5p2b0de1a117d69f54f2d1dcf027f73afef@epcas5p2.samsung.com>
2023-07-13 13:30 ` [PATCH] nvme: don't reject probe due to duplicate IDs for single-ported PCIe devices Christoph Hellwig
2023-07-13 14:02 ` Kanchan Joshi
2023-07-13 14:54 ` Keith Busch
2023-07-13 15:01 ` Jens Axboe
2023-07-13 15:20 ` Keith Busch
2026-01-20 9:54 ` xiaoke
2026-01-22 6:38 ` Christoph Hellwig [this message]
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=20260122063857.GA24621@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=xiaoke@sangfor.com.cn \
/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