Comment on proposal 09-357r0

Mark Evans Mark.Evans at wdc.com
Thu Oct 8 13:05:11 PDT 2009


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

Hi Wayne,
I'd like to discuss this further to understand what HP wants.  I am
proposing that, if a logical unit is in a low power condition as the result
of receiving a START STOP UNIT command that requests that the logical unit
go to a low power mode (i.e., with the POWER CONDITION field set to 1h, 2h,
or 3h, or with the POWER CONDITION field set to 0h and the START bit set to
zero), then the logical unit NEVER leaves the low power condition to perform
a background task.  I think that, when a SCSI target device is commanded to
do something, the target device doesn't go off and do anything on its own,
ever.  I also thing that this makes a conditional bit in the CDB be
unnecessary for these modes.
I can see that a "permission" bit allowing or disallowing a logical unit to
leave a low power condition to perform background tasks when the logical
unit is in a low power condition as a result of a power condition timer
expiring provides an excellent option for application clients.	However, I
don't think this function should be in the CDB.  I think that, if there is
one, a permission bit should be in the Power Condition Mode page, with
support for the bit indicated in the Power Condition VPD page.
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
________________________________
From: Bellamy, Wayne (mellow fellow) [mailto:Wayne.Bellamy at hp.com] 
Sent: Thursday, October 08, 2009 11:52 AM
To: Mark Evans; Gerry.Houlder at seagate.com
Cc: t10 at t10.org
Subject: RE: Comment on proposal 09-357r0
After internal group discussions, it is our opinion at HP that a permission
bit be available in the START STOP UNIT command cdb that will allow (or
disallow) the device to transition from a reduced power state to an
increased power consumption state to perform internal device checks
(background scans, internal device calibrations, etc.). If it is acceptable
to the host that these device power consumption transitions occur, then the
"permission" bit would be set to one. If it is unacceptable to the host that
these device power consumption transitions occur, then the "permission" bit
would be set to zero.
It is our opinion that devices should not consume additional power at their
own discretion when "commanded" to enter into a lower power state. This may
not necessarily apply to the power condition timers, especially the "IDLE_A"
timer (minimal power change), although it seems that the same protocol
should be established for the timers (permission bit), also.
wayne
Wayne Bellamy
HP ESS ISS
wayne.bellamy at hp.com
281-514-5196 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mark Evans
Sent: Wednesday, October 07, 2009 11:46 AM
To: Gerry.Houlder at seagate.com
Cc: t10 at t10.org
Subject: RE: Comment on proposal 09-357r0
Hi Gerry,
I'm working on clarifying the scenarios described in 09-357r0.	I've deleted
the scenario with the requirement for a two-bit field in concert with what
you wrote, as I agree that having different behaviors is too complicated,
and, at least for HDDs, we want to be able to process background tasks
unless this type of action has been specifically prohibited by a command
|from an application client.  The following are my premises for this:
a)	  If a logical unit is in a low power state as the result of a
command (e.g., a START STOP UNIT command with the power condition field and
power condition modifier field set to cause the logical unit to transition
to the idle_a power condition), then the logical unit does not change state
to process background functions when timers or device-specific events occur;
and,
b)	 If a logical unit is in a low power state as the result of a power
condition timer expiring, then the logical unit changes state as necessary
to process background functions when timers or device-specific events occur.
Stay tuned.  I hope to have a new revision out this week with the goal being
that we discuss the new revision at CAP in November so I can get more input
before I make any specific proposed wording changes to draft standards.
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
Office: 408.363.5257
Fax: 408.363.5139
Cell: 408.391.7805
Home: 408-746-3085
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Wednesday, October 07, 2009 8:33 AM
To: t10 at t10.org
Subject: Comment on proposal 09-357r0
Mark Evans recently posted proposal 09-357r0 (Relationship between low power
conditions and background tasks) and has asked for discussion of it on the
reflector. I'd like to offer my obervations.
I think the first four scenarios described in his proposal are sufficiently
described within the standards to arrive at these descriptions. The
descriptions are somewhat disk drive centric (e.g., giving special
consideration for START STOP UNIT and FORMAT comands) but I suspect these
same cases can be similary resolved for tape or other device classes with
similar device centric commands.
Scenario 5 proposes to add some mode bits to allow an initiator to choose
whether to let background tasks have priority over low power requests or
vice versa. I am not in favor of this concept.
Speaking for disk drives (other device classes may have a different
opinion), when we design background tasks they are for one reason -- to
increase the reliability of the disk drive. Let's be honest, background
tasks are a pain in the butt. They interfere with performance and power
savings, both of which are important to the customers. However the customers
also say that reliability is even more important than performance or power
savings.
My company will always want background tasks that ensure reliability to take
priority over low power conditions. All of my company's background tasks
fall into that category. Perhaps we can allow an initiator preference to
override background tasks that DO NOT enhance reliability. Then we end up
with a vendor specific interpretation of which background task might be
overridden and which ones are not, but I expect everyone will have
background tasks that are reliability related.
I think we are better off presuming background tasks are higher priority
than power savings and just leave it at that.



More information about the T10 mailing list