Re: [patch 2/5] zfcp: Handle WWPN mismatch in PLOGI payload

[James Smart <James.Smart@Emulex.Com>]

Joe Eykholt wrote:
> Christof Schmitt wrote:
>   
>> From: Christof Schmitt <christof.schmitt@de.ibm.com>
>>
>> For ports, zfcp gets the DID from the FC nameserver and tries to open
>> the port. If the open succeeds, zfcp compares the WWPN from the
>> nameserver with the WWPN in the PLOGI payload. In case of a mismatch,
>> zfcp assumes that the DID of the port just changed and we opened the
>> wrong port. This means that zfcp has to forget the DID, lookup the DID
>> again and retry.
>>     
>
> Does this happen very often?  Would you get an RSCN if a target's WWPN changed?
>   
You should - as it is supposed to re-login with the fabric, thus the 
fabric login will update the nameserver, and nameserver will generate 
the RSCN. But, there's no guarantee as to how quickly you will see the 
RSCN.   If you were on FC-AL, this happens all the time and never w/ an 
RSCN.

> Just wondering how this happens and whether libfc needs similar defenses.
> Is it due to a broken target?
>   

Libfc needs a similar defense.  You may not need to compare against the 
"nameserver" values, but you had better compare against same N_Port_ID, 
different WWPN. or vice-versa.   Its common to have RSCN events delayed, 
allowing discovery to occur in between events that may be outstanding 
(e.g. tgt plugs in - RSCN-1 event, tgt moves to another port (user error 
-kicks out and replugs) or an array failover such that WWPN moves to new 
switch port/N_Port_ID - RSCN-2 event;  and your ADISC/PLOGI based on 
RSCN-1 arrives and is responded to sooner than the nameserver propagates 
its updates and you receive RSCN-2)

-- james s