Expeditious review requested of Zone Attributes definitions rewrites

[Ralph Weber]

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

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
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