Yet Another SAM-5 Command Timeout Subproposal for 14-107

Paul Suhler Paul.Suhler at
Fri May 30 10:07:43 PDT 2014

Formatted message: <a href="">HTML-formatted message</a>

It's been suggested to me that the lack of a roar is because the lion sleeps
Wednesday night through Sunday night.
I'd like to check my understanding of 14-054r3 and how that affects my
My intent is that a command may time out any time after arrival and before it
first requests a data transfer.  In terms of T10/14-054r3, this corresponds
to command states LU_CS2:Dormant and LU_CS3:Enabled.  The expiration time is
computed when the command first arrives, as indicated by entry into
LU_CS2:Dormant; this assumes that four events take place essentially at the
same time, given adequate resources:
a)	      Arrival of the command at the SCSI Target Port.
b)	      Arrival at the TM of the SCSI Command Received message.
c)	      Arrival at the CS of the Queue Command message.
d)	      Entry into LU_CS2:Dormant.
Is that assumption correct?
I'd like not to introduce a new message.  Having specified in the model
section the conditions upon which a timeout happens, can I just specify in
the descriptions for LU_CS2 and LU_CS3 what happens when the timeout occurs? 
This would be analogous to the description of the LU_DS state, which
specifies what happens when an error occurs during command processing
Or is a message to those states necessary?
From: owner-t10 at [mailto:owner-t10 at] On Behalf Of Paul Suhler
Sent: Thursday, May 29, 2014 9:31 AM
To: T10 E-mail Reflector (t10 at
Subject: More: SAM-5 Command Timeout Subproposal for 14-107
Okay, that attempt to provoke the lions' den did not evoke any roars, so it
must have been acceptable, n'est pas?  So, here's another try:
The previously-posted revision specified when a command timeout occurs.  I
now propose to implement the timeout into the state machines by stating that
when a timeout occurs, the device server sends a (newly-defined) Time Out
Command message to the appropriate set of LU_CS states.  And I'll define the
resulting behaviors.
From: owner-t10 at<mailto:owner-t10 at> [mailto:owner-t10 at]
On Behalf Of Paul Suhler
Sent: Wednesday, May 28, 2014 4:01 PM
To: T10 E-mail Reflector (t10 at<mailto:t10 at>)
Subject: SAM-5 Command Timeout Subproposal for 14-107
Hi, George (and anyone else who wishes to comment).
As suggested in CAP in May, I'm trying to leverage the new state machines in
14-054 for defining the command deadline operations.  For example, in order
to record the arrival time of a command and set its expiration time, I want
to abandon adding an argument to the Route Command operation and instead hang
it on a newly-defined transition.  Using 14-054r3 as a base, I propose to add
the paragraph in blue: LU_CS1:Idle state LU_CS1:Idle state description
This is the initial state of the LU_CS state machine. Transition LU_CS1:Idle to LU_CS2:Dormant
This transition shall occur after receiving:
a) a Queue Command message with a Task Attribute argument set to Simple; or
b) a Queue Command message with a Task Attribute argument set to Ordered.
This transition shall include the following arguments:
a) I_T_L_Q Nexus;
b) CDB;
c) Task Attribute;
d) CRN, if any;
e) Command Priority, if any; and
f) First Burst Enabled, if any.
If this transition occurred after receiving a Queue Command message with a
Task Attribute set to simple, then the Deadline Expiration time attribute of
this command shall be set as specified in
The new subclause relies upon the proposed command deadline clock,
which is in the logical unit, and upon a command deadline value in the
proposed Command Deadline mode page.
Any problems with specifying this behavior here?  Other questions?
Paul A. Suhler, PhD
Research Staff Member
HGST Research
paul.suhler at
o: 949-476-1180 x275448
m: 949-241-6443
3001 Daimler St.
Santa Ana, CA 92705-5812<<a href="">;

More information about the T10 mailing list