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
