I_T Nexus reset TMF clarification

[Elliott, Robert (Server Storage)]

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
The I_T NEXUS RESET task management function was created for a SAS initiator
port to send after the SAS initiator device is reset, to eliminate any stale
tags that the SAS target ports might still be processing from before the
reset.
Example:
1. Controller sends a READ to a logical unit with tag 55.
2. Controller is reset, forgets everything, reboots. 
    Drive is not reset, continues working on the READ command.
3. Race condition occurs:
	Controller sends a new WRITE command with tag 55
	Drive sends a response (e.g., GOOD status) for the old READ command
with tag 55
Result: Controller thinks the response is for its WRITE command. If the READ
command was getting GOOD status and the WRITE command was getting CHECK
CONDITION status, it'll do the wrong thing with the read data.	Then, it may
get a second response with the same tag.
Before this was added, the controller options included:
a) instigate a hard reset (e.g., via SMP PHY CONTROL if the drive is behind
an expander, or via the HARD_RESET primitive if directly attached), but that
aborts commands and task management functions from by other controllers in a
multi-initiator environment.  
b) send a LOGICAL UNIT RESET task management function, but that aborts
commands and task management functions from other controllers in a
multi-initiator environment that should not be affected.  
c) send a CLEAR TASK SET task management function, but that has
multi-initiator issues and doesn't abort stale task management functions.
d) send an ABORT TASK SET task management function, but that doesn't abort
stale task management functions.
I_T NEXUS RESET restricts the impact to just the controller<->drive nexus.
A protocol like iSCSI or Fibre Channel with login/logout procedures doesn't
need this, because the logout already triggers I_T nexus loss.	SAS does not
use login/logout.
---
Rob Elliott    HP Server Storage
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph
> Weber
> Sent: Friday, 22 March, 2013 8:30 AM
> To: t10 at t10.org
> Subject: Re: I_T Nexus reset TMF clarification
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> My recollection is that the I_T Nexus Loss task management function is
> also intended to assist bridge controller devices (e.g., a bridge device
> server that detects an I_T Nexus Loss with its application client can
> forward this to the SCSI target device by sending an I_T Nexus Loss task
> management function while acting in its (the bridge's) application
> client role).
> 
> In a similar vein, the fact that a Fibre Channel LOGO is the equivalent
> of an I_T Nexus Loss provides an additional interesting justification
> for the I_T Nexus Loss task management function.
> 
> All the best,
> 
> .Ralph
> 
> On 3/21/2013 11:21 AM, Gerry Houlder wrote:
> > The original intent is that the I_T Nexus Loss TMF causes a SCSI
> > target to act in the same manner as if t has detected an I_T nexus
> > loss event on its own. This provides a way for a host to test the
> > behavior of a target and verify that the target performs all of the
> > requirements of an I_T nexus loss event. It is not useful in the case
> > of an actual I_T nexus loss event, as your email has surmised.
> >
> > An initiator might want to use this function to force a link reset/
> > speed negotiation sequence without having to interact with an SMP device.
> >
> > On Thu, Mar 21, 2013 at 10:47 AM, Hannes Reinecke <hare at suse.de
> > > wrote:
> >
> >	* From the T10 Reflector (t10 at t10.org <mailto:t10 at t10.org>),
> >	posted by:
> >	* Hannes Reinecke <hare at suse.de >
> >	*
> >	Hi all,
> >
> >	SAM-5 states in section 7.6 (I_T Nexus reset):
> >	>
> >	> Each logical unit accessible through the SCSI target port shall
> >	> perform the I_T nexus loss functions specified in
> >	> 6.3.4 for the I_T nexus on which the function request
> >	> was received, then:
> >	>
> >
> >	Typically, when an I_T Nexus loss occurs the initiator can not
> >	reach the target anymore. Depending on the transport, neither
> >	side might be able to detect this condition automatically.
> >
> >	Hence the target might not be able to receive the TMF, nor
> >	send a command completion.
> >
> >	So how is I_T nexus reset TMF supposed to be implemented?
> >	As an ex-post TMF to be send after the I_T nexus has been
> >	re-established?
> >
> >	Thanks for the clarification.
> >
> >	Cheers,
> >
> >	Hannes
> >	--
> >	Dr. Hannes Reinecke		      zSeries & Storage
> >	hare at suse.de     +49 911 74053 688
> >	SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
> >	GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
> >
> >
> >	*
> >	* For T10 Reflector information, send a message with
> >	* 'info t10' (no quotes) in the message body to majordomo at t10.org
> >	<mailto: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