FCP-4: I_T Nexus Reset

Knight, Frederick Frederick.Knight at netapp.com
Thu Nov 4 10:21:50 PDT 2010


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1011041_f.htm">HTML-formatted message</a>

Think clusters, and multi-initiators, and reasons for single connection
resets become more obvious.
We had TARGET RESET (to reset all connections to all luns in the
target).
We still have LUN RESET (to reset all connections to 1 lun in the
target).
I_T NEXUS RESET allows a reset on a single connection to 1 lun in the
target).
If I (a single initiator) am having problems, but I don't want to
disrupt anyone else, I_T NEXUS RESET is the best way to do that.  If
that doesn't fix things, I might then escalate to the LUR.
SAM5r05 6.3.3 vs. 6.3.4 shows the differences are minimal (just the
scope of the reset impact).
		Fred
From: Gerry Houlder [mailto:gerry.houlder at seagate.com] 
Sent: Thursday, November 04, 2010 10:04 AM
To: T10 Reflector
Subject: Re: FCP-4: I_T Nexus Reset
I'm not sure if this adds anything to your discussion, but here goes.
I_T Nexus Loss TMF was added to SAS as a method to force the action of
the I_T Nexus Loss timeout without disabling the protocol responses that
it would take to actually cause this timeout. It is touted as an easy
way to test what the target will do when this timeout occurs and is not
necessarily something a real system should be doing. It isn't obvious to
me that a class driver would ever choose to perform this action -- it
should probably choose to do LUN reset instead, which is more
predictable across different protocols.
It isn't obvious to me what the equivalent "nexus loss timeout" action
would be in FCP. I think it would be a logout of that initiator. My
point here is that the needed recovery steps from a SAS I_T Nexus Loss
event and the equivalent FCP action are probably different and you will
see transport dependency. The recovery action for a real "nexus loss
timeout" is probably handled in protocol specific lower level drivers
today and until the creation of the I_T Nexus Loss TMF there was no need
for the class driver to deal with it.
On Wed, Nov 3, 2010 at 1:30 PM, Knight, Frederick
<Frederick.Knight at netapp.com> wrote:
Excellent points Bob, this is going to take more thought...
My goal is still to be able to write a transport agnostic class driver.
A disk driver should be just a disk driver, our specs are broken if a
disk driver must do something like this:
If ( transport == SAS ) {I_T_NEXUS_RESET}
else
If ( transport == iSCSI ) {do a first something different}
else
If (transport == FCP ) {do a second something different}
		Fred
From: Bob.Nixon at Emulex.Com [mailto:Bob.Nixon at Emulex.Com] 
Sent: Tuesday, November 02, 2010 1:56 PM
To: Knight, Frederick; dpeterso at brocade.com; t10 at t10.org
Subject: RE: FCP-4: I_T Nexus Reset
At least a couple things bother me about this:
First, FC is, at least in theory, a multiprotocol channel. If a SCSI
application did an I_T_NEXUS_RESET, and it were mapped to LOGO, all
concurrent applications between the pair of Nx_Ports (e.g., a management
ap) would be blown away.
Second, if a SCSI application on a SAS transport sends an
I_T_NEXUS_RESET, I'm guessing it can then continue to send SAS commands;
and further, it will get any check conditions caused by the
I_T_NEXUS_RESET. If the same SCSI application requests I_T_NEXUS_RESET
on an FCP transport, causing an FC N_Port LOGO, subsequent commands can
not be sent until a new LOGIN and PRLI are completed as well; and I'm
not certain that the new login will reliably be interpreted as a
continuation of the activity of the  original I_T nexus; in which case,
the check conditions may not be forthcoming.
-	   bob
From: Knight, Frederick [mailto:Frederick.Knight at netapp.com] 
Sent: Friday, October 29, 2010 11:55 AM
To: Nixon, Bob; dpeterso at brocade.com; t10 at t10.org
Subject: RE: FCP-4: I_T Nexus Reset
There are several references to I_T Nexus loss (clauses 3.1.24, 3.1.25,
4.11, 6.4).  It sounds like you agree with my suggested resolution that
I_T_NEXUS_RESET = LOGO:
Table 4 - task management functions, SAM-4 to FCP-4
Add a row that says:
I_T_NEXUS_RESET 		       LOGO ELS (see FC-LS-2)
This does not change its optional-ness.  If it is supported, this is how
you do it (via LOGO).  This isn't much different than saying QUERY TASK
translates to REC ELS.
Application clients can't issue a LOGO.  They can issue SAM functions
(such as I_T_NEXUS_RESET).
The reason I brought this up, is because of the same reason we've
introduced a new iSCSI draft to update iSCSI to SAM-4/5 - and that is -
many host vendors refused to use some new SCSI features because it
required them to become transport aware at the class driver layer.  When
hosts must know the transport to be able to determine what parts of the
SCSI protocol work and what parts don't, they would simply prefer to
never use that function anywhere, because they never know whether it
will work or not.
That is the driving force to add it - to again make it possible to write
a transport agnostic class driver.
		Fred Knight
From: Bob.Nixon at Emulex.Com [mailto:Bob.Nixon at Emulex.Com] 
Sent: Wednesday, October 27, 2010 5:11 PM
To: dpeterso at brocade.com; t10 at t10.org
Subject: RE: FCP-4: I_T Nexus Reset
Hi, Dave, I_T_NEXUS_RESET was invented to provide a function similar to
Fibre Channel LOGO for transports that did not have the concept of
login/logout. Out of respect for established transports that had
login/logout, and for which the equivalent TMF was irrelevant,
I_T_NEXUS_LOSS was specified as optional to support.
I believe there is still no reason for FCP-x to support I_T_NEXUS_RESET;
however, FCP should make that a little more obvious.
I'd suggest adding a row to table 4 (Task management functions, SAM-4 to
FCP-4):
I_T_NEXUS_RESET...Not Supported
The "Not Supported" statement should reference a table footnote
A Logical Unit that receives a "Report Supported Task Management
Functions" command (see SPC-4) and is aware that the command has been
received via FCP should set the ITNRS bit to zero in the reply,
indicating the I_T NEXUS RESET task management function is not
supported.
-	   bob
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David
Peterson
Sent: Wednesday, October 27, 2010 11:54 AM
To: t10 at t10.org
Subject: FCP-4: I_T Nexus Reset
FCP-4 letter ballot NetApp-001 states:
"This table maps SAM-4 functions to FCP-4 functions - but the SAM I_T
NEXUS RESET function is missing (table 7 seems to indicate that LOGO ELS
has the appropriate clearing effect)."
Other than this letter ballot comment I have received no requests to
provide I_T NEXUS RESET support in FCP-4.
Please respond with your preference to include I_T NEXUS RESET in FCP-4
or not, along with your reasoning.
Thanks...Dave 



More information about the T10 mailing list