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

Joe Breher Joe.Breher at hgst.com
Thu May 21 12:14:38 PDT 2015

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

Thanks for your comments Gerry... further discussion inline...
Joe Breher
Storage Architecture Technologist
Standards Setting Organization
San Jose Research Center
HGST, a Western Digital company
(478) 2-Breher
(478) 227-3437
This e-mail may contain confidential or legally privileged information of
HGST. If you are not the intended recipient, please notify us immediately by
responding to this e-mail and then deleting it from your system.
On May 21, 2015, at 12:07 PM, Gerry Houlder
<gerry.houlder at seagate.com> wrote:
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.
Hmm. The way I see it, we have a Zone Condition attribute, with enumerated
OFFLINE, and arguably NOT WRITE POINTER. To have a separate attribute for
each possible 'zone condition' -- where exactly one can be true at any time
-- strikes me as fraught with peril.
(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
I guess we could. The counter argument that I see is that, without the 'zone'
qualifer, these attributes might be viewed by the uninitiated as having
device server wide scope. If we had classes in ZBC (an eventuality I believe
best deferred to ZBC-2), the attributes would be defined as members of the
'zone class', and as such, their scope would be explicit within the 'zone'
(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?
See above. As the guy who named the URSWRZ (Unrestricted Read in Sequential
Write Required Zone) bit, I am obviously one that prefers self-describing
precision in names, rather than brevity. That said, I did not put up a fight
when it was proposed to rename URSWRZ as UR. I'll also invoke Mr. Stevens'
guiding principle of filling drives with the words in the standards
documents, though I am unsure how tongue-in-cheek that principle might be.
(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.
Not if we employ the more rational design of a single attribute per zone
named 'Zone Condition' or similar.
(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".
I think 'if the Zone Condition is...' or 'if the Zone Condition becomes...'
might work.
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.
Indeed. I see you arrived at the same place in the end.
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
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,
Table x1 – Summary of zone attributes
Write Pointer (case change significant)
Encapsulation of the zone’s write pointer and whether that write pointer is
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
Zone Condition Implicitly Opened
Zone Condition Explicitly Opened
Zone Condition Closed
Zone Condition Full
Zone Condition Read Only
Zone Condition 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