I_T nexus loss
Bob.Nixon at emulex.com
Bob.Nixon at emulex.com
Fri Oct 31 15:16:41 PDT 2008
* From the T10 Reflector (t10 at t10.org), posted by:
* Bob.Nixon at Emulex.Com
*
For a couple reasons, I would lean toward making both the PLOGI and the
binding PRLI I_T Nexus Loss events if there were a prior nexus, even if the
service parameters are unchanged.
The first reason is practical: Table 7 makes the clearing effects for PLOGI
identical to LOGO, and the clearing effects for PRLI the same as PRLO. Since
these effects include wiping out Exchanges (and therefore, any pending SCSI
commands and task management functions), the effects are almost the same as
SAM-4 gives for Nexus Loss, lacking only the explicit requriements for
clearing ACAs and establishing the I_T NEXUS LOSS OCCURRED unit attention
condition.
The second is more philosophical: If an Initiator that is logged in sends
another PLOGI, it is a violation of good behavior, unless the Initiator has
lost state. FCP seems to make a similar presumption about PRLI, given table
7. If the Initiator has lost state, it would be best to give him notice
(unit attention) that something was going on that might be incomplete.
There is a particular case where it would be important, and that is if a
duplicate Nx_Port were placed in the Fabric, and were ping-ponging back and
forth for ownership of the Initiator identity. Unfortunately, this is not
uncommon, given the tendency of tech support to replace a questionable HBA
with a new one that has been given the same N_Port_ID/N_Port_Name, then
forgetting and putting the old one back in when no defect was found.
So I vote for adding "PLOGI on an established I_T nexus" and "PRLI on an
established I_T nexus" to the list of I_T Nexus Loss events. Do we know of
anything that would break if we did this?
- bob
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Jim.Coomes at seagate.com
Sent: Friday, October 31, 2008 9:51 AM
To: Shawn Authement
Cc: t10 at t10.org
Subject: Re: I_T nexus loss
* From the T10 Reflector (t10 at t10.org), posted by:
* Jim.Coomes at seagate.com
*
Shawn,
I was thinking that if the Service Parameters do not change in the Process
Login, the I_T_Nexus should be preserved. But I looked at FCP-4 and it
hindges on the ESTABLISH IMAGE PAIR bit. If a zero, the PRLI is Informative.
Repeated Informative PRLIs only exchange the parameters. It does not say
anything about the parameter being the same. If the ESTABLISH IMAGE PAIR bit
is one, the PRLI in Binding. The reset actions in FCP-4 clause 4.10 are
invoked and all open exchanges terminated.
I am not sure if I_T_Nexus Loss is the right status.
Jim
Shawn Authement
<Shawn.Authement@
texmemsys.com> To
Sent by: t10 at t10.org
owner-t10 at t10.org cc
No Phone Info Bob.Nixon at emulex.com
Available Subject
Re: I_T nexus loss
10/30/2008 11:58
AM
Please respond to
Shawn Authement
<Shawn.Authement@
texmemsys.com>
I am finally able to spend some time on this issue of I_T nexus loss. One
thing in your response Bob was that "PRLI causes I_T nexus loss if it changes
existing FCP-4 Service Parameters". What if it doesn't change them (i.e.,
the given service parameters are equivalent to the previous service
parameters?
To re-cap, I am investigating the following scenario:
o Nx_Port (A) (already logged in) sends PLOGI sequence with the same exact
service parameters as the original login o Nx_Port (B) sends LS_ACC o
Nx_Port (A) sends PRLI with the exact same service parameters as the original
login o Nx_Port (B) sends LS_ACC o Nx_Port (A) sends TEST UNIT READY
As this point, does Nx_Port (B) send back a status of CHECK CONDITION, a
sense key of UNIT ATTENTION, and an additional sense code (qualifier) of I_T
NEXUS LOSS HAS OCCURRED?
Thanks!
--
Shawn Authement
Sr. Software Engineer
Texas Memory Systems, Inc.
Shawn.Authement at texmemsys.com
ph: +1.713.266.3200
Bob.Nixon at Emulex.Com wrote:
Hi, Shawn, sorry to be slow in responding, but as you pointed out,
it's vague in the standads that apply (FCP-3/4 and FC-LS), and I ahd
to struggle to find anything. In the end, I came to the same
conclusion as Kevin Butt about intent.
There is some hint in both standards that a PLOGI in the presense of
an existing N_Port Login is traumatic: In FCP-4 table 7, the columns
for PLOGI and PRLI are the same as the ones for LOGO and PRLO.
In FC-LS concerning PLOGI, the third paragraph of subclause 6.3.2.1
requires treatment of new Sequences "as though a Logout had been
performed". From the standpoint of FC-LS, this is essentially
equivalent to an implicit logout, since FC-LS and FC-FS-3 specify no
persistent behavior that is not either renegotiated by PLOGI or
reflected in the collection of open Sequences.
Concerning PRLI, FC-LS insists on the next to last paragraph on page
180 (printed numbering) that it does NOT imply Process Logout;
however, the last paragraph suggests the iimpact is similar if
Service Parameters are changed. FCP-3/4 would appear to override
this, at least in part.
You're right that some clarification would be nice. I suspect that
FC-LS-2 needs to explicitly say that a PLOGI causes implicit logout
of any existing N_Port Login with the same N_Port, and FCP-4 should
say that PRLI causes I_T nexus loss if it changes existing FCP-4
Service Parameters. Others on this reflector may be able to make a
better statement. Would you like to propose text for FCP-4 and/or
FC-LS-2? Would you like me to?
- bob nixon (secretary for FCP-4 and FC-LS-2)
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Shawn
Authement
Sent: Wednesday, October 01, 2008 9:31 AM
To: t10 at t10.org
Subject: Re: I_T nexus loss
A big thank you to all who responded! I was just wondering if anyone
may know where I can reference the situations which cause an implicit
LOGO/PRLO, or maybe is this a better question to ask T11? FC-LS-2
section 6.4.4 seems to be vague on the issue, and doesn't mention
this case.
Thanks,
--
Shawn Authement
Sr. Software Engineer
Texas Memory Systems, Inc.
Shawn.Authement at texmemsys.com
ph: +1.713.266.3200
Kevin D Butt wrote:
Shawn,
Yes, when an N_Port performs a PLOGI/PRLI it logs in again.
This can be viewed as an implicit LOGO/PRLO and as stated in
4.11 of FCP-4 (
http://www.t10.org/ftp/t10/drafts/fcp4/fcp4r01.pdf) this
generates an I_T nexus loss notification.
Regards,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/
From: Shawn Authement <Shawn.Authement at texmemsys.com>
To: t10 at t10.org
Date: 09/24/2008 12:17 PM
Subject: I_T nexus loss
* From the T10 Reflector (t10 at t10.org), posted by:
* Shawn Authement <Shawn.Authement at texmemsys.com>
*
All,
I am currently researching device behavior with respect to
N_Port login
and was wondering if anyone can provide clarification.
Q: If an already-logged-in N_Port performs login again (via
PLOGI), is
this considered an I_T nexus loss as defined by SAM-3, 6.3.4?
The ENDL Fibre Channel Bench Reference implies that re-Login
causes an
implicit Logout. However, I cannot find any supporting
information in
either the FCP-3 for FC-LS specifications. My goal is to
ultimately
determine whether a SCSI Target Port should set a Unit
Attention if a
SCSI Initiator Port re-logs in.
Thank you for your your help!
--
Shawn Authement
Sr. Software Engineer
Texas Memory Systems, Inc.
Shawn.Authement at texmemsys.com
ph: +1.713.266.3200
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to
majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10
mailing list