On Mon, Apr 14, 2025 at 12:18:05PM +0000, Shinichiro Kawasaki wrote:
> On Apr 08, 2025 / 18:26, Daniel Wagner wrote:
> > Add a new test case which forcefully removes the target and setup it
> > again.
> >
> > Reviewed-by: Chaitanya Kulkarni <kch@xxxxxxxxxx>
> > Signed-off-by: Daniel Wagner <wagi@xxxxxxxxxx>
>
> When I ran this test case for tr=loop, it fails.
>
> The out file is as follows:
>
> $ cat ./results/nodev_tr_loop/nvme/061.out.bad
> Running nvme/061
> iteration 0
> grep: /sys/class/nvme-fabrics/ctl//state: No such file or directory
> grep: /sys/class/nvme-fabrics/ctl//state: No such file or directory
> grep: /sys/class/nvme-fabrics/ctl//state: No such file or directory
> grep: /sys/class/nvme-fabrics/ctl//state: No such file or directory
> grep: /sys/class/nvme-fabrics/ctl//state: No such file or directory
> grep: /sys/class/nvme-fabrics/ctl//state: No such file or directory
> expected state "connecting" not reached within 5 seconds
>
> And kernel reported the "invalid parameter" message:
>
> [ 888.896492][ T3112] run blktests nvme/061 at 2025-04-14 21:11:18
> [ 888.937128][ T3158] loop0: detected capacity change from 0 to 2097152
> [ 888.949671][ T3161] nvmet: adding nsid 1 to subsystem blktests-subsystem-1
> [ 888.997790][ T3170] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
>
> In the v1 series, you noted that your fc-loop fixes will avoid the
> failure.
Yes, the fcloop fixes will address the fc transport failures. The above
failure is caused by the same issue as in 060: the loop transport
doesn't know about reconnect_delay, thus the requires should list tcp,
rdma and fc as valid transport and not loop.
> But the failure was observed with tr=loop, so I'm not sure fc-loop fixes
> will avoids the failure. I'm wondering if this test case is for rdma/tcp/fc
> transports only and suspecting it may not be intended for the loop
> transport.
Yes, this is correct. My test script listed only tcp, rdma and fc, so I
didn't catch the error with loop.
> > + nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
> > + state_file="/sys/class/nvme-fabrics/ctl/${nvmedev}/state"
> > + for ((i = 0; i <= 5; i++)); do
> > + echo "iteration $i"
> > +
> > + _nvmet_target_cleanup
> > +
> > + _nvmf_wait_for_state "${def_subsysnqn}" "connecting" || return 1
> > + echo "state: $(cat ${state_file})"
>
> The line above needs one more pair of double quotations to avoid the
> shellcheck warn:
>
> echo "state: $(cat "${state_file}")"
I didn't know this is actually allowed and even required. Sure, will
update the patches accordingly.
Thanks,
Daniel
