Comment on proposal 09-357r0
Mark.Evans at wdc.com
Wed Oct 7 09:45:35 PDT 2009
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910075_f.htm">HTML-formatted message</a>
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
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