Fw: SAS Link Reset, a down port, and I_T nexus loss

Edward.Younk at hitachigst.com Edward.Younk at hitachigst.com
Sun Apr 24 18:12:41 PDT 2011


* From the T10 Reflector (t10 at t10.org), posted by:
* Edward.Younk at hitachigst.com
*
Hi everyone,
This is a resend, since I haven't see this get out on the reflector yet.
Edward Younk
Firmware/Hardware Engineer
Hitachi Global Storage Technologies
office: (507) 322-2116, fax: (507) 322-2400
Internet: Edward.Younk at hgst.com
----- Forwarded by Edward Younk/US/HGST on 04/24/2011 08:11 PM -----
Edward Younk/US/HGST 
04/22/2011 05:05 PM
To
t10 at t10.org
cc
Subject
Fw: SAS Link Reset, a down port, and I_T nexus loss
Hi everyone,
I think I found the answer to my question.
The PL_OC1:Idle state machine handles the case where a port has no enabled 
phys.  If our target consists of two ports of one phy each, then the phy 
being disabled would cause us to go from the PL_OC2:Overall Control state 
to the PL_OC1:Idle state. In this state, if a Transmit frame message is 
received by the transport layer, the PL_OC state machine should respond 
with a "no phys in port" message to the transport layer.
Up is the ST_TFR state machine, a "no phys in port" message should 
generate a "nexus loss" message to the application layer. 
Therefore, in the case I described below, I think the correct answer is to 
declare a  nexus loss as soon as we detect the phy go down, and we need to 
send a frame to the initiator. Am I reading this right?
Edward Younk
Firmware/Hardware Engineer
Hitachi Global Storage Technologies
office: (507) 322-2116, fax: (507) 322-2400
Internet: Edward.Younk at hgst.com
----- Forwarded by Edward Younk/US/HGST on 04/22/2011 04:50 PM -----
Edward Younk/US/HGST 
04/22/2011 11:10 AM
To
t10 at t10.org
cc
Subject
SAS Link Reset, a down port, and I_T nexus loss
Hi SAS guys,
I have a question that I hope one of you can answer.  Section 4.4.1 of 
spl07 states: "The link reset sequence has no effect on the transport 
layer and application layer unless the link reset sequence disrupts frame 
transmission. " 
 In addition, section 4.5 describes the conditions which cause the I_T 
nexus loss timer to run.  They include:
Open reject (No destination, Pathway blocked, reserved initialized 0, 1, 
reservered stop 0, 1) or a Open timeout. 
I feel that a down link should also  start this timer, but I can't find 
anything in the standard to justify this interpretation.
Consider the following scenario with a multiple initiator dual port SAS 
target environment.
Commands being executed on both ports of the target by multiple 
initiators.
1. Write command received on port A.
2. Target asks for data from the initiator, receives all the data, and 
proceeds to write the data to the media.
3. The link on port A goes down for whatever reason. (Frame transmission 
for the write was not disrupted.)
4. The target finishes the write, and prepares to send status.	However, 
the port is now down and a link reset sequence is being run to recover the 
link.
So here's the question, how long should the target wait for the link to 
come back up, before giving up trying to send status for the write 
command. In addition, how long should the target hang on to commands for 
the initiators communicating through that port.  If the target implements 
a unified queue for all initiators, the initiators on port B could be 
waiting a long time for their commands to execute.  It seems that the only 
way out of this would be for the initiators on port B to hit that port 
with an abort queue or hard reset, in order to clean the queue of commands 
|from initiators who were talking on port A.
It seems to me that a down port should be handled in the same manner as 
Open reject(No destination) i.e., start the I_T nexus loss timer.  Am  I 
right, or am I wrong?  Please enlighten me. 
Thanks for the help.
Edward Younk
Firmware/Hardware Engineer
Hitachi Global Storage Technologies
office: (507) 322-2116, fax: (507) 322-2400
Internet: Edward.Younk at hgst.com
--=_alternative 0006A71D8625787D_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Hi everyone,</font>
<br>
<br>
<br><font size=2 face="sans-serif">This is a resend, since I haven't see
this get out on the reflector yet.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Edward Younk<br>
Firmware/Hardware Engineer<br>
Hitachi Global Storage Technologies<br>
office: (507) 322-2116, fax: (507) 322-2400<br>
Internet: Edward.Younk at hgst.com<br>
</font>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Edward
Younk/US/HGST on 04/24/2011 08:11 PM -----</font>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Edward Younk/US/HGST</b>
</font>
<p><font size=1 face="sans-serif">04/22/2011 05:05 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">t10 at t10.org</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Fw: SAS Link Reset, a down
port, and I_T nexus loss</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br><font size=2 face="sans-serif">Hi everyone,</font>
<br>
<br><font size=2 face="sans-serif">I think I found the answer to my
question.</font>
<br>
<br><font size=2 face="sans-serif">The PL_OC1:Idle state machine handles
the case where a port has no enabled phys. &nbsp;If our target consists
of two ports of one phy each, then the phy being disabled would cause us
to go from the PL_OC2:Overall Control state to the PL_OC1:Idle state. In
this state, if a Transmit frame message is received by the transport layer,
the PL_OC state machine should respond with a "no phys in port"
message to the transport layer.</font>
<br>
<br><font size=2 face="sans-serif">Up is the ST_TFR state machine, a "no
phys in port" message should generate a "nexus loss" message
to the application layer. &nbsp;</font>
<br>
<br>
<br><font size=2 face="sans-serif">Therefore, in the case I described below,
I think the correct answer is to declare a &nbsp;nexus loss as soon as
we detect the phy go down, and we need to send a frame to the initiator.
Am I reading this right?</font>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Edward Younk<br>
Firmware/Hardware Engineer<br>
Hitachi Global Storage Technologies<br>
office: (507) 322-2116, fax: (507) 322-2400<br>
Internet: Edward.Younk at hgst.com<br>
</font>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Edward
Younk/US/HGST on 04/22/2011 04:50 PM -----</font>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Edward Younk/US/HGST</b>
</font>
<p><font size=1 face="sans-serif">04/22/2011 11:10 AM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">t10 at t10.org</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">SAS Link Reset, a down port,
and I_T nexus loss</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Hi SAS guys,</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">I have a question that I hope one of
you can answer. &nbsp;Section 4.4.1 of spl07 states: "The link reset
sequence has no effect on the transport layer and application layer unless
the link reset sequence disrupts frame transmission. " </font>
<br>
<br><font size=2 face="sans-serif">&nbsp;In addition, section 4.5 describes
the conditions which cause the I_T nexus loss timer to run. &nbsp;They
include:</font>
<br><font size=2 face="sans-serif">Open reject (No destination, Pathway
blocked, reserved initialized 0, 1, reservered stop 0, 1) or a Open timeout.
</font>
<br>
<br><font size=2 face="sans-serif">I feel that a down link should also
&nbsp;start this timer, but I can't find anything in the standard to justify
this interpretation.</font>
<br>
<br><font size=2 face="sans-serif">Consider the following scenario with
a multiple initiator dual port SAS target environment.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Commands being executed on both ports
of the target by multiple initiators.</font>
<br>
<br><font size=2 face="sans-serif">1. Write command received on port
A.</font>
<br><font size=2 face="sans-serif">2. Target asks for data from the
initiator,
receives all the data, and proceeds to write the data to the media.</font>
<br><font size=2 face="sans-serif">3. The link on port A goes down for
whatever reason. (Frame transmission for the write was not disrupted.)</font>
<br><font size=2 face="sans-serif">4. The target finishes the write, and
prepares to send status. &nbsp;However, the port is now down and a link
reset sequence is being run to recover the link.</font>
<br>
<br><font size=2 face="sans-serif">So here's the question, how long should
the target wait for the link to come back up, before giving up trying to
send status for the write command. In addition, how long should the target
hang on to commands for the initiators communicating through that port.
&nbsp;If the target implements a unified queue for all initiators, the
initiators on port B could be waiting a long time for their commands to
execute. &nbsp;It seems that the only way out of this would be for the
initiators on port B to hit that port with an abort queue or hard reset,
in order to clean the queue of commands from initiators who were talking
on port A.</font>
<br>
<br><font size=2 face="sans-serif">It seems to me that a down port should
be handled in the same manner as Open reject(No destination) i.e., start
the I_T nexus loss timer. &nbsp;Am &nbsp;I right, or am I wrong? &nbsp;Please
enlighten me. &nbsp;</font>
<br>
<br>
<br><font size=2 face="sans-serif">Thanks for the help.</font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Edward Younk<br>
Firmware/Hardware Engineer<br>
Hitachi Global Storage Technologies<br>
office: (507) 322-2116, fax: (507) 322-2400<br>
Internet: Edward.Younk at hgst.com<br>
</font>
--=_alternative 0006A71D8625787D_=--
*
* 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