From: Christoph Hellwig <hch@lst.de>
To: Yao Sang <sangyao@kylinos.cn>
Cc: Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org, kbusch@kernel.org,
axboe@kernel.dk, sagi@grimberg.me, shinichiro.kawasaki@wdc.com
Subject: Re: [PATCH v2] nvme: recompute multipath zoned limits from ready paths
Date: Mon, 25 May 2026 09:30:12 +0200 [thread overview]
Message-ID: <20260525073012.GA5201@lst.de> (raw)
In-Reply-To: <20260525064026.2fxlbmztsfyzzn25@sang-pc>
On Mon, May 25, 2026 at 02:40:26PM +0800, Yao Sang wrote:
> What I saw was not different live paths of the same namespace
> reporting different zoned limits. On a QEMU VM with native NVMe
> multipath enabled, two emulated NVMe controllers shared the same ZNS
> namespace and advertised CMIC.MULTI_CTRL, so the kernel created a
> multipath namespace head. In that setup, both controller paths
> reported max_open_zones=16 and max_active_zones=16, while the
> multipath namespace head for the same namespace reported 0/0.
>
> I also checked Identify Namespace data through both controllers. In
> both cases, nvme zns id-ns reported mor=15 and mar=15, so I did not
> observe any path-to-path MOR/MAR mismatch. The mismatch was between
> the namespace head and the controller paths.
They have to. The high-level approach in your earlier patch is
the correct one. The problem is just that we use the block-level
stacking for totally different things (multipath and complicated
DM setups). The long-term strategy is to unwind that, but for
now I think you should just open code what you did there in the
nvme-multipath driver.
prev parent reply other threads:[~2026-05-25 7:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 7:58 [PATCH v2] nvme: recompute multipath zoned limits from ready paths Yao Sang
2026-05-22 9:21 ` Christoph Hellwig
2026-05-25 6:40 ` Yao Sang
2026-05-25 7:30 ` 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=20260525073012.GA5201@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=sangyao@kylinos.cn \
--cc=shinichiro.kawasaki@wdc.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 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.