Things I don't like about proposal 08-126

Mark Overby MOverby at nvidia.com
Mon Mar 24 16:37:50 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* Mark Overby <MOverby at nvidia.com>
*
However, in a real SCSI world you'd get an ASC(Q) to the other initiator (at
least that's the way I understood the proposal) indicating that an
initializing command is required.
On 3/24/08 1:35 PM, "James.C.Hatfield at seagate.com"
<James.C.Hatfield at seagate.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * James.C.Hatfield at seagate.com
> *
> For dual ported devices: Another reason for not supporting SLEEP is that
> one initiator could put it to sleep
> without the knowledge of another.
> 
> Thank You !!!
> -----------------------------------------------------------------
> Jim Hatfield
> Seagate Technology LLC
>    e-mail:  James.C.Hatfield at seagate.com
>    s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
>    voice:  720-684-2120
>    fax....:  720-684-2711
> ==========================================
> 
> 
>		   
>	       Gerry.Houlder at sea
>	       gate.com
>	       Sent by: 						  To
>	       owner-t10 at t10.org	 t10 at t10.org
>	       (952) 402-2869						  cc
>		   
>								     Subject
>	       03/24/2008 12:59 	 Things I don't like about proposal
>	       PM			 08-126
>		   
>		   
>		   
>		   
>		   
>		   
> 
> 
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> 
> Proposal 08-126 will reintroduce the SLEEP state to SCSI. I am opposed to
> this for several reasons:
> 
> (a) Investigation of my company's SATA implementation (which includes both
> STANDBY and SLEEP states) shows that SLEEP state has the same power savings
> as STANDBY. Since SLEEP provides no power savings over STANDBY there is no
> advantage for it. I recommend other companies look into what they might do
> differently for SLEEP versus STANDBY so I can be sure my analysis is
> typical of the industry.
> 
> (b) SLEEP is a lot more trouble for the initiator in terms of what it has
> to do to wake up a target and initialize it to accept commands. If it
> provides no power savings, the extra trouble is not worth it.
> 
> (c) Even if I thought SLEEP was useful, using a timer expiration to invoke
> SLEEP is a bad thing. If a target goes into SLEEP mode without the
> initiator's knowledge, the initiator will probably try to send it a command
> and get unexpected timeout. The initiator will likely assume (by today's
> interpretation) the target has died and will flag it as such. SATA gets
> around this issue by only allowing SLEEP to be entered by express command
> from the initiator. In this way the initiator should know that the target
> is put to SLEEP and should know that the WAKEUP procedure is needed before
> sending a command. This suggests that even interfaces that define and use
> SLEEP do not want this state to be entered by targets on their own accord
> (e.g., timer expiration).
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
-----------------------------------------------------------------------------
------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.	If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------
------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list