[PATCH 0/5] nvmet/nvmet_fc: add events for discovery controller rescan

[James Smart]

On 10/29/2017 9:11 AM, Sagi Grimberg wrote:
> James,
>
>> A transport may have a transport-specific mechanism that can signal
>> when discovery controller content has changed and request a host
>> to reconnect to the discovery controller.
>>
>> FC is such a transport. RSCNs may be generated by the FC port with
>> the discovery server, with the RSCNs then broadcast to the FC-NVME
>> hosts. A host, upon receiving the RSCN, would validate connectivity
>> then initiate a discovery controller rescan, allowing new subsystems
>> to be connected to or updating subsystem connectivity tables.
>
> How does this fit with possible future discovery enhancements discussed
> in nvme TWG right now? The notification for discovery records change
> will not be transport specific in the future.

Its independent yet can coexist very well.

Currently, the FC-NVME standard strongly suggests a discovery controller 
on each target. Having this simple notification avoids lots of 
long-lived connections and rescans are done only when/where needed - 
with no change in any standard. It works very well on current products.  
There's nothing preventing it coexisting with long-lived discovery 
controller connections and other configurations of discovery servers.

I don't buy into your last statement yet. Long lived discovery 
connections are fine and an admin can already configure a set of systems 
as they describe. I also expect any attempt to mandate centralized 
discovery controllers to have a fair number of issues to be worked out 
not just with hosts but with targets and cross-fabric issues and I 
believe there will be pushback to give complete control of presentation 
to third party entity.  In some respects, the history of iSNS/SLP for 
iSCSI gave a brief example of trying to go down this path.

-- james