Newest EXTENDED COPY model (and rewrite) docs uploaded

Ralph Weber roweber at IEEE.org
Sun Aug 21 14:36:56 PDT 2011


* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
I have uploaded a matched set of model/rewrite documents for
EXTENDED COPY:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-078r6.pdf
http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-079r8.pdf
I have reviewed these uploads from pillar to post. In my mind, they are
ready for substantial CAP consideration and possible recommendation to
T10. Only 14% of the 165 pages in the pair of documents are totally
free of change bars.
(Translation: I have found all the bugs I can find. It is your turn now.)
A bevy of open questions also await resolution by CAP. What follows is
a summary of the ones that are more "interesting" to me.
++ Should the EXTENDED COPY command definition be revised to cause *any*
truncation of the parameter list to result in an error? The nature of
the modern EXTENDED COPY parameter list is such that loss of any part
of it renders proper processing of the command difficult, if not
impossible. (See page 30 in 11-078r6)
++ Is the LIST ID USAGE field still needed in commands where the List
Identifier field is 32 bits wide? (See page 31 in 11-078r6)
++ Is it possible/practical/wise to limit EXTENDED COPY support for
the Processor device type to interactions with the copy managers in
dedicated copy engine products? The existing support has not been made
obsolete because of the need for dedicated copy engines to use some
device type (which by tradition is Processor). In all other respects
the Processor device type has been obsolete since SPC-2.
(See pages 41 & 48 in 11-078r6)
++ Does the HDD (held data discarded) bit make any sense in the
parameter data returned by the RECEIVE COPY STATUS(LID4) command?
Would it not be better to limit the presence of HDD to those commands
that deal directly with held data (e.g., RECEIVE COPY DATA(LID4))?
(See page 95 in 11-078r6 and page 9 in 11-079r8).
++ In the RECEIVE COPY STATUS(LID4) command, why not require the
copy manager to set the EXTENDED COPY COMPLETION STATUS field to
TASK ABORTED if the copy operation/command gets whacked by an ABORT
TASK task management function? True, this probably differs from the
status (not)returned by the command, but why should that fact limit
the RECEIVE COPY STATUS(LID4) command's behavior?
(See page 97 in 11-078r6)
++ How to the Third-party Copy VPD page limits on number of concurrent
copies interact with the SBC-3 commands (e.g., WRITE USING TOKEN)?
(See page 119 in 11-078r6).
++ In EXTENDED COPY commands, is it necessary for the copy manager
to prevent the same LBA from appearing two or more times in a ROD?
The POPULATE TOKEN has such a restriction, but is it a universal
norm? (See page 6 in 11-079r8)
++ Is it acceptable to have the Logical Block Provisioning replication
rules for EXTENDED COPY be expressed as a 'may'?
(See page 26 in 11-079r8)
++ In the new ROD Type & ROD Token Type support VPD descriptor, should
a copy manager be prohibited from indicating that it converts point in
time copy ROD Tokens to access on reference RODs internally?
(See page 42 in 11-079r8)
Gird your loins for a "really good time" in Westborough. ...or...
Avoid some of the flames by sending your comments to the author early.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list