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@xxxxxxxxxxxxx> >> --- >> 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