Expeditious review requested of Zone Attributes definitions rewrites

Ballard, Curtis C (HP Storage) curtis.ballard at hp.com
Tue May 19 09:38:37 PDT 2015


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

I believe that the group agreed that the contents of the attributes should be
kept as abstract constructs such as named values (e.g., true, false, foobar)
rather than hard coded values (e.g., zero, one, 38h) so that no particular
internal implementation was prescribed since the internal value of the
attributes will never be exposed.
I didn’t feel like the group came to a solid consensus for the exact
wording regarding how the named values and attributes came together.  In
general the group seemed fine with the existing “shall have” and “shall
cause” type wording but maybe after sleeping on it people are feeling drawn
to the old traditional ‘set to’.
Curtis Ballard
Hewlett-Packard Company
+1 970 898 3013 / Tel
Curtis.Ballard at hp.com / Email
Fort Collins, CO
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of George
Penokie
Sent: Tuesday, May 19, 2015 10:01 AM
To: Ralph Weber
Cc: Gerry Houlder; t10 at t10.org
Subject: Re: Expeditious review requested of Zone Attributes definitions
rewrites
Ralph,
My interpretation of the discussion was that the "set to" wording would be
used for the state variables. I don't recall were the attributes ended up.
Bye for now,
George Penokie
Avago Technologies
Attn: George Penokie
4109 Manor View Dr NW
Rochester , MN 55901
952-921-2495
george.penokie at avagotech.com
On Tue, May 19, 2015 at 10:47 AM, Ralph Weber
<Ralph.Weber at wdc.com> wrote:
Topic One
During yesterday's call, I specifically asked if anybody wanted to insist
that the "set to" nomenclature be used for zone attributes.
The discussion favoring the current wording revolved around the notion that
the definitions of zoned attributes should be enough different from the way
field values are described so as to ensure that the standard was not seen as
requiring any specific implementation for zone attributes.
When the dust settled, I heard no concerted demands for the "set to"
nomenclature. Now, upwards of 90% of the markups in the transmitted PDF
amount to exactly such demands.
Did I misread the tenor of opinions on yesterday's call? Has use of the "set
to" nomenclature become the consensus position?
Topic Two
Regarding the "big comment" ...
Given the previous efforts that are reflected in Curtis' proposed text, I
have no objection to the following two changes.
The device may allocate and deallocate non-sequential write resources at any
time during or after the processing of one or more non-sequential write
commands. As a result, the host is not able to associate the value of the
Non-Sequential Write Resources Active zone attribute with any series of write
commands that start at the write pointer, as recommended by this standard,
mixed with non-sequential write commands.
If a non-sequential write operation occurs in a zone, then the device server
may cause the Non-Sequential Write Resources Active zone attribute to have a
true value.  The device server may change the Non-Sequential Resources Active
zone attribute to a false value at any time if non-sequential write resources
are no longer allocated for that zone.
 ...
Action by the host (e.g., sending a RESET WRITE POINTERS EXT command (see
5.2.8) specifying this zone) may or may not be required to cause the value of
the Non-Sequential Write Resources Active zone attribute to change from true
to false.
However, I object to the other changes in the "big comment" as described in
topic three and topic four.
Topic Three
The application client is owed some shred of consistent behavior as regards
the Non-Sequential Write Resources Active zone attribute. Therefore, the
following paragraph (or something equivalent) ought to remain in the
proposal.
If the device has not processed a non-sequential write command in a zone
since the last time a RESET WRITE POINTERS EXT command (see 5.2.8) was
processed, then the Sequential Writes Affecting Performance zone attribute
shall have a false value.
Topic Four
To maintain a consistency of descriptions across all zone attribute
definitions, the following paragraph is critical to the success of the
proposal.
Empty zones, read only zones, and offline zones have a false value in the
Non-Sequential Write Resources Active zone attribute (see 4.5.2.4.2,
4.5.2.4.7, and 4.5.2.4.8, respectively).
All the best,
.Ralph
________________________________
From: Gerry Houlder
[gerry.houlder at seagate.com]
Sent: Tuesday, May 19, 2015 9:55 AM
To: Ralph Weber
Cc: t10 at t10.org<mailto:t10 at t10.org>
Subject: Re: Expeditious review requested of Zone Attributes definitions
rewrites
My comments are included in the attachment. There is one big comment and a
handful of editorial nits.
On Tue, May 19, 2015 at 8:20 AM, Ralph Weber
<Ralph.Weber at wdc.com> wrote:
The two-page, recently posted
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-159r0.pdf contains the rewrites
that resulted from yesterday's review of 15-113r3. The goal of this separate
document that is not on any agenda is to put the new text in the hands of
interested parties ASAP.
Comments on 15-159r0 that are received by the close of business today will be
reflected in the ZAC zone state machine document posted tomorrow morning for
review by the conference call later that day.
All the best,
.Ralph



More information about the T10 mailing list