Joe Eykholt wrote:
Christof Schmitt wrote:
From: Christof Schmitt <christof.schmitt@xxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
