[T13] Integrating zone attribute ideas from T13 ZAC call

Ralph Weber Ralph.Weber at wdc.com
Thu May 21 12:09:18 PDT 2015


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

By 'already done in ZBC', I suspect the virtues of glossary entries along the
lines of 'closed zone' and 'empty zone' were being extolled. Pleasing to the
eye, smaller numbers of words in the glossary seemed to result in larger
numbers of words in the body text.
Compare a common phrase in the body text.
  *   ... a zone that is an empty zone ...
  *   ... a zone in Zone Condition Empty ...
Beyond this, one must remember the hewn cries from Monday about the engineers
in at least three companies being too familiar with 'zone condition' to allow
the term to be ripped willy-nilly from the standard.
Thus beginneth the responses to the most recent reflector posting, the
remainder of which are interspersed amongst the original comments.
________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of Gerry Houlder
[gerry.houlder at seagate.com]
Sent: Thursday, May 21, 2015 1:07 PM
Cc: t13 at t13.org; t10 at t10.org
Subject: Re: [T13] Integrating zone attribute ideas from T13 ZAC call
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.
[ROW] While I do not presume to understand UML, I have been given to
understand that the unqualified usage of 'attribute' is limited to UML
models. (Are there any 'volunteers' to UML model zones?)
(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.
[ROW] The proposed text contains the strongest statement that is likely to be
allowed, "Only one zone attribute in the Zone Condition enumeration is true
at any point in time." Anything stronger (e.g., a 'shall') would have to be
viewed as placing requirements on the state machine.
(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".
[ROW] If the wording in the proposed example passes muster with a wide enough
audience, then the wording from the bulleted summary above ought to serve
nicely throughout the body text. (Of course, there is an 'if' in this
remark.)
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.
[ROW] My reason for devising the enumeration of zone attributes revolves
around the T10 precedents for the naming of enumerations of similarly used
values.
Although past ZBC proposals have used ALL CAPS for such names, the actual T10
precedent for ALL CAPS usage (e.g., in SAM-5) limits such names to cases
where the standard defines the a precise coded value for each ALL CAPS name.
The precedent for cases where the standard places no requirements on the
coded value is SMALL CAPS, not ALL CAPS, names as placeholders for the
vendor-specific values. Non-believers are encouraged to examine the
difference between status values and Service Responses in any conveniently
available copy of SAM-5.
If I were still a consultant, I would marvel at the income generating
possibilities of EMPTY zone condition, but instead I am now the person who
would be answering a couple of emails daily, which makes the opportunity less
thrilling.
Viewed from this perspective, the blank-page options associated with creating
a never-before-standardized-in-SCSI enumeration of zone attributes each of
which has a precedent-free format was, frankly, too attractive to pass up.
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