On 7/13/23 10:49, Max Gurtovoy wrote:
On 13/07/2023 9:00, Hannes Reinecke wrote:
On 7/13/23 02:12, Max Gurtovoy wrote:
On 12/07/2023 15:04, Daniel Wagner wrote:
On Mon, Jul 10, 2023 at 07:30:20PM +0300, Max Gurtovoy wrote:
On 10/07/2023 18:03, Daniel Wagner wrote:
On Mon, Jul 10, 2023 at 03:31:23PM +0300, Max Gurtovoy wrote:
I think it is more than just commit message.
Okay, starting to understand what's the problem.
A lot of code that we can avoid was added regarding the --context
cmdline
argument.
Correct and it's not optional to get the tests passing for the fc
transport.
why the fc needs the --context to pass tests ?
A typical nvme test consists out of following steps (nvme/004):
// nvme target setup (1)
_create_nvmet_subsystem "blktests-subsystem-1" "${loop_dev}" \
"91fdba0d-f87b-4c25-b80f-db7be1418b9e"
_add_nvmet_subsys_to_port "${port}" "blktests-subsystem-1"
// nvme host setup (2)
_nvme_connect_subsys "${nvme_trtype}" blktests-subsystem-1
local nvmedev
nvmedev=$(_find_nvme_dev "blktests-subsystem-1")
cat "/sys/block/${nvmedev}n1/uuid"
cat "/sys/block/${nvmedev}n1/wwid"
// nvme host teardown (3)
_nvme_disconnect_subsys blktests-subsystem-1
// nvme target teardown (4)
_remove_nvmet_subsystem_from_port "${port}" "blktests-subsystem-1"
_remove_nvmet_subsystem "blktests-subsystem-1"
The corresponding output with --context
run blktests nvme/004 at 2023-07-12 13:49:50
// (1)
loop0: detected capacity change from 0 to 32768
nvmet: adding nsid 1 to subsystem blktests-subsystem-1
nvme nvme2: NVME-FC{0}: create association : host wwpn
0x20001100aa000002 rport wwpn 0x20001100aa000001: NQN
"blktests-subsystem-1"
(NULL device *): {0:0} Association created
[174] nvmet: ctrl 1 start keep-alive timer for 5 secs
// (2)
nvmet: creating nvm controller 1 for subsystem
blktests-subsystem-1 for NQN
nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349.
[374] nvmet: adding queue 1 to ctrl 1.
[1138] nvmet: adding queue 2 to ctrl 1.
[73] nvmet: adding queue 3 to ctrl 1.
[174] nvmet: adding queue 4 to ctrl 1.
nvme nvme2: NVME-FC{0}: controller connect complete
nvme nvme2: NVME-FC{0}: new ctrl: NQN "blktests-subsystem-1"
// (3)
nvme nvme2: Removing ctrl: NQN "blktests-subsystem-1"
// (4)
[1138] nvmet: ctrl 1 stop keep-alive
(NULL device *): {0:0} Association deleted
(NULL device *): {0:0} Association freed
(NULL device *): Disconnect LS failed: No Association
and without --context
run blktests nvme/004 at 2023-07-12 13:50:33
// (1)
loop1: detected capacity change from 0 to 32768
nvmet: adding nsid 1 to subsystem blktests-subsystem-1
nvme nvme2: NVME-FC{0}: create association : host wwpn
0x20001100aa000002 rport wwpn 0x20001100aa000001: NQN
"nqn.2014-08.org.nvmexpress.discovery"
why does this association to discovery controller created ? because
of some system service ?
Yes. There are nvme-autoconnect udev rules and systemd services
installed per default (in quite some systems now).
And it's really hard (if not impossible) to disable these services (as
we cannot be sure how they are named, hence we wouldn't know which
service to disable.
Right. We shouldn't disable them IMO.
can we configure the blktests subsystem not to be discovered or add
some access list to it ?
But that's precisely what the '--context' thing is attempting to do ...
I'm not sure it is.
Exposing the subsystem is from the target configuration side.
Additionally, the --context (which is in the initiator/host side),
according to Daniel, is there to distinguish between different
invocations. I proposed that blktests subsystem will not be part of
discoverable fabric or protected somehow by access list. Therefore, no
additional invocation will happen.
Hmm. Maybe we can tweak blktest to use it's own HostNQN, and always pass
that for any nvme-cli call.
Daniel?
Cheers,
Hannes
