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

Gerry Houlder gerry.houlder at seagate.com
Wed Nov 28 07:09:51 PST 2012


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

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,
thenprocess 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