Behavior of TEST UNIT READY command in idle and standby power conditions

Knight, Frederick Frederick.Knight at netapp.com
Thu Nov 29 06:41:50 PST 2012


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

No, not quite.	You're jumping to conclusions.
I'm suggesting that you forget about your internal state for just a minute
and focus on the visible behavior instead.  "INITIALIZING COMMAND REQUIRED"
is not necessarily only for when you are actually in the stopped condition
(remember, these are models).  There may be times that you want the initiator
to think you are in the stopped condition (even if you are not).  Yes, I
know, engineering sacrilege.  But, SCSI has always been more about the
visible behavior than actual verifiable internal state.
If you can process a READ command without error, then you are not in the
stopped condition (you return GOOD status).
If you cannot process a READ command and you need more time to be able to get
to the point where you are able to process the READ command, then what do you
do to get that time?  You have lots of choices (some of which work better in
some circumstances than others).  One choice to get more time is to get the
initiator to send a START UNIT command (because initiators know that spin-up
may take more time).  So, you tell them you are in the stopped condition to
trigger the action you need (you tell the host INITIALIZING COMMAND
REQUIRED).
I guess, what I'm saying, is that the answer isn't a simple black or white
(always GOOD, or always CHECK CONDITION).  Sometimes, you have to evaluate
your internal situation and make a decision as to which response is
appropriate for that situation.
		Fred
From: Gerry Houlder [mailto:gerry.houlder at seagate.com]
Sent: Wednesday, November 28, 2012 10:10 AM
To: Knight, Frederick
Cc: Pat LaVarre; Matthew Jacob; T10 Reflector
Subject: Re: Behavior of TEST UNIT READY command in idle and standby power
conditions
Since "initializing command required" is only used for Stopped condition, it
sounds like you want TUR to report GOOD status from idle and standby
conditions. Am i interpreting you correctly?
On Wed, Nov 28, 2012 at 6:30 AM, Knight, Frederick
<Frederick.Knight at netapp.com> wrote:
SPC and SBC already say that if the command is able to be processed, then
process it.
If the device went to idle, and it gets a READ, and the device is able to
process the READ, then do it.  NO CHECK CONDITION.
Therefore, if the device gets a TUR and the device is able to process a READ
(no matter what power condition it is in), then the status is GOOD.  There is
no CHECK CONDITION on that TUR.  AND, as was pointed out, it is still
possible that the device will change state in between the TUR and the READ,
so the TUR could still return GOOD and the READ return a CHECK CONDITION.
If the device is NOT able to process a READ, then when the TUR comes in, the
device returns CHECK CONDITION - NOT READY - INITIALIZING COMMAND REQUIRED. 
The host sends START UNIT.  When the START UNIT completes the host sends the
READ (it might also resend the TUR before sending the READ).  If the device
needs time to get ready, it takes that time during the processing of the
START UNIT command.
Not complex - just 2 cases.  GOOD or INITIALIZING COMMAND REQUIRED.
		Fred Knight
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org>
[mailto:owner-t10 at t10.org<mailto:owner-t10 at t10.org>] On Behalf Of Pat LaVarre
Sent: Tuesday, November 27, 2012 7:27 PM
To: Matthew Jacob
Cc: Gerry Houlder; T10 Reflector
Subject: Re: Behavior of TEST UNIT READY command in idle and standby power
conditions
Of course I trust you all to ask me to sign out if I'm tangent'ing
un-entertainingly ...
...
Q: How could we encourage opinion to converge on such a question?
This Option for Check Condition/ Not Ready from Tur is, by its apparent
crowd-sourced design, an escape from simpler models, a way of allowing the
Target to fall into a state where it needs a Start Unit signal from the host.
With that option left open, Scsi is less simple and more flexible. Thus Scsi
is Scsi, not Ata. Targets that don't need that complexifying option
interoperate more broadly, but naive Hosts then fall unknowing into
supporting only those simpler Targets.
Can we gather votes around simplifying Scsi? Either radically to exclude the
Targets weirdly slow to return from Low Power, or inclusively to burden even
the more common and otherwise simpler quick-to-return targets with the Low
Power Check Condition? Or should we leave Scsi as conflicted with itself as
it always has been here?
...
Like Test Unit Ready has always been intrinsically paradoxical with itself. I
mean, just suppose the Target transitions to Low Power in the narrow time
window before the last Test Unit Ready or Request Sense Poll and the arrival
of a Read Cdb. Well then the Read must handle that condition. So tell me
again what the point of the Poll was? It's just to spend power to help
pretend that the host can handle spontaneous Target transitions to Low Power,
right?
The simplest kind of Scsi, the most power efficient, would forbid the host
poll on these inescapably logical grounds. Q: Poll with Test Unit Ready? A:
No. Q: Poll with Request Sense? A: No. Q: Cope with slow Target? A: Yes. Like
go exercise the discovery features, new in this last decade or two, that help
the host guess how unresponsive a Target might acceptably be, in seconds
elapsed.



More information about the T10 mailing list