On 10/07/2023 11:27, Daniel Wagner wrote:
On Thu, Jul 06, 2023 at 07:11:58PM +0300, Max Gurtovoy wrote:
On 20/06/2023 16:27, Daniel Wagner wrote:
When the host has enabled the udev/systemd autoconnect services for the
fc transport it interacts with blktests and make tests break.
nvme-cli learned to ignore connects attemps when using the
--context command line option paired with a volatile configuration. Thus
we can mark all the resources created by blktests and avoid any
interaction with the systemd autoconnect scripts.
why would we like to ignore connect attempts during blktests ?
The problem I observed is that there were two connect attempts (one triggered
via udev and one via the test itself) which disturbed the test. The interference
resulted into a complete hang of the test case:
https://lore.kernel.org/linux-nvme/6g53yj5afhhonwf2psf7ft2gkakkwewy7klkix3y3u6uclpa5w@tt2yfzigyxgg/
We define unique nqn/ids/etc. So we never should disturb other running
services, unless it uses the same parameters, which shouldn't happen.
Yes, that should do the decoupling between udev and blktests.
Agree on setting the hard coded values for hostnqn and hostid instead of
reading the /etc/nvme/* files. This should do the work IMO, isn't it ?
Do you mean that nvme-cli will ignore the udev trigger when a different hostnqn
is invovled? At least for the well-known discover controller the hostqnq
doesn't work. Though not sure if I understood you correctly here.
All I was saying is that your issue would have been fixed easily by 2-3
LOC by removing the usage of /etc/nvme/* files that are usually
configured by system administrator and use a default values for blktests
hostnqn and hostid.
The usage of --context in blktests is redundant IMO.
