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

Knight, Frederick Frederick.Knight at netapp.com
Wed Nov 28 04:30:55 PST 2012


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

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] 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