Re: [PATCH 26/35] monitor: implement starting discovery controllers on startup

quoted

quoted

If the -U/--startup option is used, nvme monitor looks for exsiting
nvme controllers on startup, and runs a discovery on the associated
transport address (connection); i.e. tries to connect to a
discovery
subsystem on the same address, retrieve the discovery log pages,
and (if --autoconnect is given) connect all listed controllers.

Oh no no no no... This is a completely wrong assumption to make.
Nothing
suggest that an nvme controller will have a discovery controller on
the
same port.

There is a discovery controller and an NVM controller, the only
connection between the two is that a discovery controller can
refer to an nvme controller (or a different discovery controller).

Information about discovery controllers may be obtained in different
ways, but it absolutely cannot be obtained by any nvme controller.

Now I understand a bit more on the --keep discussion. The monitor
should today get discovery controller endpoints from a conf file
(maybe discovery.conf) and in the future by any other automatic
way, not even looking into the currently connected nvme controllers.

I hear you. I'll drop this in the next version, no problem.

I didn't expect that probing for a discovery controller was a problem.

It's not a "problem" in the sense that nothing devastating will happen.
it's just wrong. One can also randomize a transport endpoint and attempt
to connect to it.

IIUC, if we get an fc_udev_device event for a NVMe remote port, we
can't be sure that that remote port offers a discovery controller,
either. We try to connect, and give up if it fails.

I'm assuming that this is what the spec mandates the host should do,
which is not the case here.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme