Comment on proposal 09-357r0
Bellamy, Wayne (mellow fellow)
Wayne.Bellamy at hp.com
Thu Oct 8 11:52:08 PDT 2009
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910082_f.htm">HTML-formatted message</a>
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
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.
HP ESS ISS
wayne.bellamy at hp.com
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
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;
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.
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
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