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

[Gerry Houlder]

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

OK, so then that would lead to wording examples like "If the Zone Condition
attribute is set to Empty, then ..." or "A Zone Condition attribute value
of Empty indicates ...". Is this what you had in mind Joe?
Are we OK with having a Zone Condition Attribute and a ZONE CONDITION
field? Ralph was intentionally make the wording a little different for
these two to reduce the chance of confusing them. Maybe there wouldn't be
any confusion since one is always follows by "attribute" and the other
always followed by "field".
On Thu, May 21, 2015 at 2:14 PM, Joe Breher <Joe.Breher at hgst.com> wrote:
>  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 values of EMPTY, IMPLICIT OPEN, EXPLICIT OPEN, CLOSED, READ
> ONLY, FULL, 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 false.
>
>
>  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' qualifier.
>
>  (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
>> 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
>>
>
>
>
>
>
>
>
>
>
>
>
>
>