[PATCH blktests] tests/nvme/031: fix connecting faiure

Shinichiro Kawasaki shinichiro.kawasaki at wdc.com
Mon Sep 11 17:18:40 PDT 2023


On Sep 11, 2023 / 14:16, Daniel Wagner wrote:
> On Mon, Sep 11, 2023 at 11:00:17AM +0000, Shinichiro Kawasaki wrote:
> > > nvmf_wait_for_state "${def_subsysnqn}" "live"
> > > nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
> > > 
> > > We could make this a bit more generic and move it into the connect
> > > helper. What do you think?
> > 
> > This nvme state file check looks a bit complicated, but looks more robust than
> > "nvme connect" command exit status check. Do you think that "nvme connect" can
> > fail even when "nvme connect" command returns good status? If so, your approach
> > will be the way to choose.
> 
> Currently, 'nvme connect' is a synchronous call for tcp/rdma but not for
> fc. 'nvme connect' for tcp/rdma will report an error if something is
> wrong but not for fc, because it always return successfully.
> 
> The nvme/005 is exposing the behavior differences between the
> transports. My long time goal is to address and make all transport
> behave the same way (unification of the state machines). But as it
> currently stands fc would need someting like this to make sure we are
> not blindly reporting success just because the 'nvme connect' call is
> successful.
> 
> This type of check would make the test suite more robust and better in
> detecting errors.

Thanks for the explanation. I agree that the nvme state file check in
_nvme_connect_subsys() it the more robust and the better.



More information about the Linux-nvme mailing list