Re: [PATCH 1/1] nvme: always enable multipath
From: John Meneghini
Date: Fri Nov 22 2024 - 12:49:59 EST
On 11/22/24 10:39, Keith Busch wrote:
On Fri, Nov 22, 2024 at 01:09:25PM +0100, Christoph Hellwig wrote:
On Thu, Nov 21, 2024 at 05:03:21PM -0500, Bryan Gurney wrote:
Since device-mapper multipath will no longer be operating on NVMe
devices, there is no longer a need to set CONFIG_NVME_MULTIPATH=n.
Always enable NVMe multipath, remove CONFIG_NVME_MULTIPATH, and use
the code paths that would be used if CONFIG_NVME_MULTIPATH=y.
As mentioned last round not having to build the not tiny multipath
code for embedded systems and other small builds that never require
multipathing still seems like a sensible idea.
It's not just embedded either. I have plenty of single port datacenter
PCIe NVMe's that claim multi-controller capabilities. I think it's some
artifact of SRIOV that some versions of the firmware can bring.
Anyway, we only use the one physical function, so they're certainly not
multipath devices here. We disable the CONFIG option because while the
nvme multipath IO overhead is low, it's not zero.
So you're saying you want to keep CONFIG_NVME_MULTIPATH and simply remove the modparam nvme_core.multipath? (I know I said we
were going to do that but that's before Bryan and I started testing his changes with blktests. I think we can fix that.)
The problem with this solution is: when you build a kernel with CONFIG_NVME_MULTIPATH=n you get exactly the same thing as
CONFIG_NVME_MULTIPATH=y with nvme_core.multipath=n. You get a separate /dev/nvmeNN entry for every namespace/controller path,
minus the multipath.c code.
So, I don't see the point. If you really want to stop supporting user space multi-path solutions like DMMP with nvme we need to
stop creating multiple dev entries for multi-path controllers, no matter what.
Note that this multi-pathing stuff is a part of the confusion in UDEV, like I spoke about at ALPPS this year. One reason why the
/dev/disk/by-path symlinks are so broken is because the kernel has at least three different ways to configure multi-pathing
support for nvme devices.
We've been saying we're going to do this since since v5.18.
So how do we want to do this?
-
- if (!multipath) {
- dev_warn(ctrl->device,
- "Found shared namespace %d, but multipathing not supported.\n",
- info->nsid);
- dev_warn_once(ctrl->device,
- "Support for shared namespaces without CONFIG_NVME_MULTIPATH is deprecated and will be removed in Linux 6.0.\n");
- }
commit ce8d78616a6b637d1b763eb18e32045687a84305
Author: Christoph Hellwig <hch@xxxxxx>
Date: Tue Mar 15 13:27:07 2022 +0100
nvme: warn about shared namespaces without CONFIG_NVME_MULTIPATH
Start warning about exposing a namespace as multiple block devices,
and set a fixed deprecation release.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Keith Busch <kbusch@xxxxxxxxxx>
(master) > git name-rev --tags --name-only ce8d78616a6b637d1b763eb18e32045687a84305
nvme-5.18-2022-03-17^0