[PATCH 07/13] libmultipath: Add delayed removal support

[Nilay Shroff]

On 4/10/26 2:25 PM, John Garry wrote:
> On 10/04/2026 08:06, Nilay Shroff wrote:
>>>    # Part b: Ensure writes work for intermittent disconnect
>>>      _nvme_connect_subsys
>>>
>>>      nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
>>>      ns=$(_find_nvme_ns "${def_subsys_uuid}")
>>>      echo 10 > "/sys/block/"$ns"/delayed_removal_secs"
>>>      bytes_written=$(run_xfs_io_pwritev2 /dev/"$ns" 4096)
>>>      if [ "$bytes_written" != 4096 ]; then
>>>          echo "could not write successfully initially"
>>>      fi
>>>      sleep 1
>>>      _nvme_disconnect_ctrl "${nvmedev}"
>>>      sleep 1
>>>      ns=$(_find_nvme_ns "${def_subsys_uuid}")
>>>      if [[ "${ns}" = "" ]]; then
>>>          echo "could not find ns after disconnect"
>>>      fi
>>>      _delayed_nvme_reconnect_ctrl &
>>>      sleep 1
>>>      bytes_written=$(run_xfs_io_pwritev2 /dev/"$ns" 4096)
>>>      if [ "$bytes_written" != 4096 ]; then
>>>          echo "could not write successfully with reconnect"
>>>      fi
>>
>> It seems there may be a race here if we attempt to write to $ns before
>> the reconnect has completed in _delayed_nvme_reconnect_ctrl.
>>
>> If the intention is simply to verify that the controller reconnect occurs
>> within the delayed removal window and test pwrite,
> 
> Not exactly. I want to verify that if I write between the disconnect and the reconnect, then we write succeeds.

Okay, got it — I think I misunderstood the intention earlier.

So the goal here is to verify that if a write is issued during the
delayed removal window is in progress (i.e., when there is temporarily
no active path), the write should be queued. Once the reconnect succeeds,
the queued write should then be unblocked and sent to the target.

If this understanding is correct, then this looks like a good test
to me.

Thanks,
--Nilay