FCP-4: I_T Nexus Reset

Gerry Houlder gerry.houlder at seagate.com
Thu Nov 4 07:03:34 PDT 2010


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

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