I_T Nexus reset TMF clarification
gerry.houlder at seagate.com
Thu Mar 21 09:21:04 PDT 2013
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1303213_f.htm">HTML-formatted message</a>
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), 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
> Thanks for the clarification.
> 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
More information about the T10