[RFC PATCHv2 2/3] nvme: introduce multipath_head_always module param

Nilay Shroff nilay at linux.ibm.com
Mon Apr 28 00:39:13 PDT 2025



On 4/28/25 12:27 PM, Hannes Reinecke wrote:
> On 4/25/25 12:33, Nilay Shroff wrote:
>> Currently, a multipath head disk node is not created for single-ported
>> NVMe adapters or private namespaces. However, creating a head node in
>> these cases can help transparently handle transient PCIe link failures.
>> Without a head node, features like delayed removal cannot be leveraged,
>> making it difficult to tolerate such link failures. To address this,
>> this commit introduces nvme_core module parameter multipath_head_always.
>>
>> When this param is set to true, it forces the creation of a multipath
>> head node regardless NVMe disk or namespace type. So this option allows
>> the use of delayed removal of head node functionality even for single-
>> ported NVMe disks and private namespaces and thus helps transparently
>> handling transient PCIe link failures.
>>
>> By default multipath_head_always is set to false, thus preserving the
>> existing behavior. Setting it to true enables improved fault tolerance
>> in PCIe setups. Moreover, please note that enabling this option would
>> also implicitly enable nvme_core.multipath.
>>
>> Signed-off-by: Nilay Shroff <nilay at linux.ibm.com>
>> ---
>>   drivers/nvme/host/multipath.c | 70 +++++++++++++++++++++++++++++++----
>>   1 file changed, 63 insertions(+), 7 deletions(-)
>>
> I really would model this according to dm-multipath where we have the
> 'fail_if_no_path' flag.
> This can be set for PCIe devices to retain the current behaviour
> (which we need for things like 'md' on top of NVMe) whenever the
> this flag is set.
> 
Okay so you meant that when sysfs attribute "delayed_removal_secs" 
under head disk node is _NOT_ configured (or delayed_removal_secs
is set to zero) we have internal flag "fail_if_no_path" is set to 
true. However in other case when "delayed_removal_secs" is set to 
a non-zero value we set "fail_if_no_path" to false. Is that correct?

> And it might be an idea to rename this flag to 'multipath_always_on',
> so 'multipath_head_always' might be confusing for people not familiar
> with the internal layout of the nvme multipath driver.
> 
Okay, I like this "multipath_always_on" module param. I'd rename
it in the next patch.

Thanks,
--Nilay




More information about the Linux-nvme mailing list