[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=r1505214_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