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

Pat LaVarre p.lavarre at
Tue Nov 27 16:26:32 PST 2012

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

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