From: Nilay Shroff <nilay@linux.ibm.com>
To: John Garry <john.g.garry@oracle.com>,
Hannes Reinecke <hare@suse.de>,
hch@lst.de, kbusch@kernel.org, sagi@grimberg.me, axboe@fb.com,
martin.petersen@oracle.com,
james.bottomley@hansenpartnership.com, hare@suse.com
Cc: jmeneghi@redhat.com, linux-nvme@lists.infradead.org,
linux-scsi@vger.kernel.org, michael.christie@oracle.com,
snitzer@kernel.org, bmarzins@redhat.com,
dm-devel@lists.linux.dev, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 07/13] libmultipath: Add delayed removal support
Date: Fri, 10 Apr 2026 12:36:31 +0530 [thread overview]
Message-ID: <da2bfbb0-70ef-4c3a-a235-1343b4a02489@linux.ibm.com> (raw)
In-Reply-To: <ccfc867c-e744-42a2-9b22-47245a6c06d7@oracle.com>
On 4/9/26 6:30 PM, John Garry wrote:
> On 09/04/2026 07:37, Nilay Shroff wrote:
>>>
>>> You mean a common blktests testcase, right?
>>>
>>> For NVMe, that test would:
>>> a. try to remove NVMe ko when we have the delayed removal active
>>> b. ensure that we can queue for no path
>>>
>>> I suppose that a common testcase could be possible (with dm mpath), but doesn't dm have its own testsuite?
>>>
>> Yes, I'd add a blktest for 'queue_if_no_path' feature. But as we know we have
>> separate test suite for dm under blktests, I'd first target nvme testcase and
>> then later add another testcase for dm-multipath.
>
> Testing a. is a challenge to be effective, as we would typically not be able to remove the nvme modules anyway due to many other references.
>
> For b, how about something like the following:
>
> set_conditions() {
> _set_nvme_trtype "$@"
> }
>
> _delayed_nvme_reconnect_ctrl() {
> sleep 2
> _nvme_connect_subsys
> }
>
> test() {
> echo "Running ${TEST_NAME}"
>
> _setup_nvmet
>
> local nvmedev
> local ns
> local bytes_written
>
> _nvmet_target_setup
> _nvme_connect_subsys
>
> # Part a: Ensure writes fail when no path returns
> 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
> bytes_written=$(run_xfs_io_pwritev2 /dev/"$ns" 4096)
> if [ "$bytes_written" == 4096 ]; then
> echo "wrote successfully after disconnect"
> fi
> sleep 10
> ns=$(_find_nvme_ns "${def_subsys_uuid}")
> if [[ !"${ns}" = "" ]]; then
> echo "found ns after delayed removal"
> fi
>
> #echo "now part 2"
> # 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, then it may be sufficient
to:
- perform the reconnect, and
- then validate the write (pwrite) afterwards.
In that case, we could either:
- run _delayed_nvme_reconnect_ctrl in the foreground, or
- open-code the reconnect directly in the script before issuing the write.
> sleep 10
> ns=$(_find_nvme_ns "${def_subsys_uuid}")
> if [[ "${ns}" = "" ]]; then
> echo "could not find ns after delayed reconnect"
> fi
>
> # Final tidy-up
> echo 0 > /sys/block/"$ns"/delayed_removal_secs
> nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
> _nvme_disconnect_ctrl "${nvmedev}"
> _nvmet_target_cleanup
>
> echo "Test complete"
> }
Otherwise overall this looks good to me.
Thanks,
--Nilay
next prev parent reply other threads:[~2026-04-10 7:06 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 15:32 [PATCH 00/13] libmultipath: a generic multipath lib for block drivers John Garry
2026-02-25 15:32 ` [PATCH 01/13] libmultipath: Add initial framework John Garry
2026-03-02 12:08 ` Nilay Shroff
2026-03-02 12:21 ` John Garry
2026-02-25 15:32 ` [PATCH 02/13] libmultipath: Add basic gendisk support John Garry
2026-02-26 2:16 ` Benjamin Marzinski
2026-02-26 9:04 ` John Garry
2026-03-02 12:31 ` Nilay Shroff
2026-03-02 15:39 ` John Garry
2026-03-03 12:39 ` Nilay Shroff
2026-03-03 12:59 ` John Garry
2026-03-03 12:13 ` Markus Elfring
2026-02-25 15:32 ` [PATCH 03/13] libmultipath: Add path selection support John Garry
2026-02-26 3:37 ` Benjamin Marzinski
2026-02-26 9:26 ` John Garry
2026-03-02 12:36 ` Nilay Shroff
2026-03-02 15:11 ` John Garry
2026-03-03 11:01 ` Nilay Shroff
2026-03-03 12:41 ` John Garry
2026-03-04 10:26 ` Nilay Shroff
2026-03-04 11:09 ` John Garry
2026-04-14 10:03 ` John Garry
2026-04-14 11:43 ` Nilay Shroff
2026-04-14 13:10 ` John Garry
2026-03-04 13:10 ` Nilay Shroff
2026-03-04 14:38 ` John Garry
2026-02-25 15:32 ` [PATCH 04/13] libmultipath: Add bio handling John Garry
2026-03-02 12:39 ` Nilay Shroff
2026-03-02 15:52 ` John Garry
2026-03-03 14:00 ` Nilay Shroff
2026-02-25 15:32 ` [PATCH 05/13] libmultipath: Add support for mpath_device management John Garry
2026-02-25 15:32 ` [PATCH 06/13] libmultipath: Add cdev support John Garry
2026-02-25 15:32 ` [PATCH 07/13] libmultipath: Add delayed removal support John Garry
2026-03-02 12:41 ` Nilay Shroff
2026-03-02 15:54 ` John Garry
2026-04-08 11:28 ` John Garry
2026-04-08 15:41 ` Hannes Reinecke
2026-04-08 16:28 ` John Garry
2026-04-09 6:37 ` Nilay Shroff
2026-04-09 13:00 ` John Garry
2026-04-10 7:06 ` Nilay Shroff [this message]
2026-04-10 8:55 ` John Garry
2026-04-10 9:09 ` Nilay Shroff
2026-04-10 9:49 ` John Garry
2026-04-10 10:51 ` Nilay Shroff
2026-04-10 11:49 ` John Garry
2026-02-25 15:32 ` [PATCH 08/13] libmultipath: Add sysfs helpers John Garry
2026-02-27 19:05 ` Benjamin Marzinski
2026-03-02 11:11 ` John Garry
2026-02-25 15:32 ` [PATCH 09/13] libmultipath: Add PR support John Garry
2026-02-25 15:49 ` Keith Busch
2026-02-25 16:52 ` John Garry
2026-02-27 18:12 ` Benjamin Marzinski
2026-03-02 10:45 ` John Garry
2026-02-25 15:32 ` [PATCH 10/13] libmultipath: Add mpath_bdev_report_zones() John Garry
2026-02-25 15:32 ` [PATCH 11/13] libmultipath: Add support for block device IOCTL John Garry
2026-02-27 19:52 ` Benjamin Marzinski
2026-03-02 11:19 ` John Garry
2026-04-09 15:20 ` John Garry
2026-02-25 15:32 ` [PATCH 12/13] libmultipath: Add mpath_bdev_getgeo() John Garry
2026-02-25 15:32 ` [PATCH 13/13] libmultipath: Add mpath_bdev_get_unique_id() John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=da2bfbb0-70ef-4c3a-a235-1343b4a02489@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=axboe@fb.com \
--cc=bmarzins@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=hare@suse.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=james.bottomley@hansenpartnership.com \
--cc=jmeneghi@redhat.com \
--cc=john.g.garry@oracle.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=michael.christie@oracle.com \
--cc=sagi@grimberg.me \
--cc=snitzer@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.