[PATCH v3 3/3] nvme_fc: Avoid duplicate associations between same port pairs
James Smart
james.smart at broadcom.com
Mon Sep 18 09:28:35 PDT 2017
On 9/18/2017 9:12 AM, Christoph Hellwig wrote:
> On Thu, Sep 14, 2017 at 10:38:43AM -0700, James Smart wrote:
>> Rescans can occur due to subsystem list changes on an FC remoteport.
>> Rescans may attempt to reconnect to subsystems where there is already
>> an association in place. There should only be 1 association in place
>> at a time for the following tuple:
>> <hostnqn, hostid, host FC port, target FC port, subnqn>
> There is absolutely no requirement for this limitation in the NVMe
> spec.
True. But it makes little sense to allow it as it creates a 2nd
controller, thus multiple devices for the namespaces, along the same "hw
path". I.e. now multipath has 2 nvme devices for the same hw path with
no changes in availability and consuming more resources on host and target.
The desire for FC is to have the same dynamic discovery that it has for
SCSI. Thus the udev events that kick off scanning. The events are posted
when connectivity is first detected as well as conditions where the
discovery server content may have changed (new subsystems added for
example). Since those events are ignorant of what's already connected,
it make no sense to create additional controllers/devices if there's
already a controller connected.
The alternative is to drive all connections manually which makes a very
difficult to manage system for an administrator, especially on
"cable-pull" scenarios. There is no need for this with FC.
-- james
More information about the Linux-nvme
mailing list