[T13] [T13] Integrating zone attribute ideas from T13 ZAC call

Gerry Houlder gerry.houlder at seagate.com
Thu May 21 11:07:44 PDT 2015


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

Regarding the new "zone condition ... attributes": i was OK with what Ralph
had already done in ZBC, but i can go along with this approach. I am starting
to get annoyed with how the terms are growing into unwieldy mouthfuls,
however. For instance: "Zone Condition Empty zone attribute"? How about
something simpler, like Empty Condition attribute, or just Empty attribute.
(a) We should be able to just call them attributes instead of zone
attributes. The wording of the definition could be similar to to the SAM-5
definition, thusly: "when referring to zoned block devices, a named property
that has a range of values". In our case the range will only include true and
false.
(b) Using "zone condition" instead of just "condition" just makes the name
longer. If all of the names have the same word in them, then the word doesn't
help in discriminating between the different conditions. In fact, now that we
are setting ourselves up for always calling these things the <something or
other> attribute, perhaps we are good enough with the term "Empty attribute",
since "condition" being in the name of all the attributes also doesn't add
anything that discriminates between the choices?
(c) these attributes need a rule that states that exactly one of them can be
true at a time and the others shall be false.
(d) when referring to these attributes in other parts of the standard, do we
have to say "if the Empty attribute is true, then ..."? (Or maybe "...the
Empty attribute becomes true".
Another question: is there a reason we are not thinking of the zone condition
as a single attribute that has a range of values? For example, a Zone
Condition attribute that can be one of [Empty, Implicitly Open, Explicitly
Open, Closed, Full, Read Only, Offline]? This would avoid the need to have a
"only one can be true at a time" rule.
On Thu, May 21, 2015 at 5:39 AM, Ralph Weber
<Ralph.Weber at wdc.com> wrote:
Reading the tea leaves from the zone attributes discussion was impossible in
real time. In effect, a new style element is being built from existing style
elements (e.g., UML attributes). It is hard to tell where the boundaries lie
for this construction effort.
So, taking the zone attributes issues as a starting point, here are some
ideas that push the envelope rather farther than some might be willing to
stomach.
Note that only enough information is shown to initiate this discussion (i.e.,
this is not a draft proposal in email form).
Don’t be shy about sharing concerns on one or both of these reflectors.
All the best,
.Ralph
Table x1 – Summary of zone attributes
Attribute
Description
Write Pointer (case change significant)
Encapsulation of the zone’s write pointer and whether that write pointer is
valid
Zone Condition …
Enumeration of like names zone attributes only one of which is true based on
the zone’s state
RWP Recommended
minor changes as per call’s discussion
Non-Sequential Write Resources Active
minor changes as per call’s discussion
Write Pointer zone attribute
The Write Pointer zone attribute represents the combination of the zone’s
write pointer (see write pointer zones overview) and whether that write
pointer is valid  (see table in state machine).
Zone Condition zone attributes
The Zone Condition zone attributes enumerate the possible states of the zone
in the Zone Condition state machine (see state machine) as shown in table x2
to indicate the current Zone Condition state for the zone. Only one zone
attribute in the Zone Condition enumeration is true at any point in time.
Table x2 – Zone Condition attributes
Zone Condition zone attribute
Zone state indicated for the zone if the
Zone Condition zone attribute is true
Zone Condition Empty
ZC1:Empty
Zone Condition Implicitly Opened
ZC2:Implicit_Open
Zone Condition Explicitly Opened
ZC3:Explicit_Open
Zone Condition Closed
ZC4:Closed
Zone Condition Full
ZC5:Full
Zone Condition Read Only
ZC6:Read_Only
Zone Condition Offline
ZC7:Offline
Example – A zone that is described as a zone “in Zone Condition Closed”
is a zone in the ZC4:Closed state.
Note – A glossary entry is still needed for Zone Condition Open, along the
lines of …
Zone Condition Open
zone in Zone Condition Explicitly Opened or Zone Condition Implicitly Opened
RWP Recommended
minor changes as per call’s discussion
Non-Sequential Write Resources Active
minor changes as per call’s discussion



More information about the T10 mailing list