[PATCH] nvme-cli: nvmf-connect at .service: Remove matching from default syntax

[Hannes Reinecke]

On 12/17/21 9:43 PM, Martin Wilck wrote:
> On Fri, 2021-12-17 at 11:32 -0800, James Smart wrote:
>> commit 53aab69a0add added the "--matching" argument to the systemd
>> connect script that issues connect-all to a discovery controller.
>> When
>> this argument is used, only discovery log entries whose target port
>> traddr's match the traddr of the discovery controller will be
>> connected
>> to.  This eliminates the ability to do referrals by the discovery
>> controller.
>>
>> Revert the commit so that the "--matching" argument is not default
>> behavior.
> 
> Hm, I guess you have to do revert this if it breaks referrals.
> 
> The intention of my patch was not to suppress referrals. Unless I'm
> mistaken, a referral is a log page entry that lists another discovery
> controller, on which then another discovery is carried out. The "--
> matching" parameter was intended to ignore log page entries listing
> ordinary (non-discovery) subsystems on if their traddr didn't match the
> discovery controller's traddr.
> 
But this does assume that each I/O controller will share the port the 
discovery controller.
Which is not mandated by the spec (even if most arrays currently 
implement it that way), and it's certainly not true for TPAR 8010 CDCs.

So this is not the right way of approaching this 'problem'.

> I still think connecting to those entries is wrong more often than not.
> In the environment I was testing in back then, IIRC there were 4
> discovery controllers, each listing every subsystem on every
> controller. The host would try to connect to every subsystem 4 times,
> resulting in error messages 3 out of 4 times. With --matching, these
> errors could be avoided.
> 
This issue is a direct result of the NVMe spec not putting any 
restriction on what the discovery log pages can contain.
They might even contain entries not reachable from the current host port.

So again, the concept of 'matching' ports is wrong, and should be 
replaced by a concept of 'reachable' ports.
We can easily figure that out for FC, and it should be doable for TCP, too.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare at suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer