[T13] Integrating zone attribute ideas from T13 ZAC call

[Joe Breher]

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

I have already weighed on part of this upthread. Further comments below....
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 1:09 PM, Ralph Weber
<Ralph.Weber at wdc.com> wrote:
(a) ...
[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?)
T10 explicitly discussed this possibility early in the process - I think it
was New Orleans, but may be mistaken. At the time, the wisdom of the group
seemed to be that this would be nice, but would likely delay the delivery of
a standard. Accordingly, the sentiment was to defer until ZBC-2. I have
always held this in mind as a work product I would deliver for such, should
nobody else want the task. That said, the invention of bald attributes is a
big leap in that direction. If now is the time it need be done, we could go
there.
(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.
As mentioned previously, I have a _strong_ preference for a single Zone
Condition attribute, which can take on any of the enumerated values of EMPTY,
IMPLICIT OPEN, EXPLICIT OPEN, CLOSED, READ ONLY, FULL, OFFLINE, and arguably
NOT WRITE POINTER (case issues deferred). Is there some benefit of the
attribute explosion which I am not seeing?
...
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.
<Oh - there's the benefit I was wondering about>
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.
<Nope - I'm still not getting it>
Perhaps this is where I take up the case issues deferred above. I think the
group has so far tried to avoid tying these attributes to specific
implementations, correct? And that part of this property of
implementation-free would be that we will not employ required concrete values
for the range of allowable values which such a attribute may take on? If so,
what is the remaining problem with a single Zone Condition attribute that can
take on the enumerated values of (SMALL CAPS) EMPTY, IMPLICIT OPEN, EXPLICIT
OPEN, CLOSED, READ ONLY, FULL, OFFLINE, and arguably NOT WRITE POINTER?
I'm not sure how the difference between status values and Service Responses
in SAM-5 supports an argument for an explosion of zone condition attributes.
As an example culled from SAM-5, the Command class contains at most one
Service Response attribute. It does not need two separate such Service
Response attributes in order to represent both COMMAND COMPLETE and SERVICE
DELIVERY OR TARGET FAILURE. The single Service Response attribute may take on
any one of the range of values [ COMMAND COMPLETE, SERVICE DELIVERY OR TARGET
FAILURE ].
Accordingly, I think a single Zone Condition attribute (per zone) is
sufficient and proper. This single attribute can take on any one of the range
of values [ EMPTY, IMPLICIT OPEN, EXPLICIT OPEN, CLOSED, READ ONLY, FULL,
OFFLINE, NOT WRITE POINTER ].
...