Extended Copy command error reporting

Gerry Houlder gerry.houlder at seagate.com
Thu Oct 17 07:00:50 PDT 2013


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

The documentation you want is already present in SPC-4. Clause 4.5.8
provides a table of sense keys and general principles for their use.
The COPY ABORTED row "Indicates a third-party copy command (see 5.16.3) was
aborted after some
data was transferred but before all data was transferred". This certainly
indicates a partially processed copy operation.
The ILLEGAL REQUEST row says "If the device server detects an invalid
parameter in the CDB, it shall terminate the command without altering the
medium. If the device server detects an invalid parameter in the additional
parameters supplied as data, the device server may have already altered the
medium." This provides an opening for using illegal Request in parameter
data in situations that could have caused alteration of the medium, but for
COPY commands there is a more specific sense key (i.e., COPY ABORTED) to
use, so it should be used when it is applicable.
On Wed, Oct 16, 2013 at 8:21 PM, Ralph Weber <Ralph.Weber at wdc.com> wrote:
>  Paul,
>
> In a nutshell, this message is supporting David's comments.
>
> For EXTENDED COPY, the design intent is that ILLEGAL REQUEST is used when
> there is no chance data has been written somewhere. The flip-side of the
> coin is COPY ABORTED, which (if we have written the spec as intended) comes
> into play after the standard can reasonably assume data has been written
> somewhere.
>
> These choices cannot be perfectly specified. A half dozen read-only
> segment descriptors could have been processed perfectly and the first write
> segment descriptor was where the error was found. The spec still says
> return COPY ABORTED. There is a limit to how well we can read the tea
> leaves from the T10 Ivory Tower.
>
> N.B. This division of the loaves applies only to EXTENDED COPY, and it is
> simply the way we have tried to write the standard. It is a matter of how
> we want the specification to read (and/or how we think we have written it).
> Our intention does not constitute a requirement on implementations
> (indirectly or otherwise). The only requirements are those spelled out in
> SPC-4.
>
> All the best,
>
> .Ralph
>  ------------------------------
> *From:* owner-t10 at t10.org [owner-t10 at t10.org] on behalf of Black, David [
> david.black at emc.com]
>
> *Sent:* Wednesday, October 16, 2013 6:10 PM
> *To:* Paul Hughes; t10 at t10.org
> *Subject:* RE: Extended Copy command error reporting
>
>   The high-level intent is:
>
>
>
> ILLEGAL REQUEST indicates that nothing happened before the error was
> detected (e.g., no change to stored data).
>
> COPY ABORTED indicates that something may have happened before the error
> was detected (e.g., stored data may have been changed).
>
>
>
> In this context, the verb “processing” refers to doing the actions
> indicated by the segment descriptor.	There is no requirement to validate
> all the segment descriptors before processing any of them.
>
>
>
> For an out of range LBA error with an ILLEGAL REQUEST sense key,
> additional information can be provided via a field pointer in the sense
> data to indicate the block count field in the segment descriptor that
> caused the problem.
>
>
>
> Thanks,
> --David
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Paul
> Hughes
> *Sent:* Wednesday, October 16, 2013 1:55 PM
> *To:* t10 at t10.org
> *Subject:* Extended Copy command error reporting
>
>
>
> I'm uncertain how some types of Extended Copy errors should be reported,
> for example whether the copy manager should set the sense key to COPY
> ABORTED or not.
>
>
>
> In SPC-4 rev 36i, section 5.16.7.3 states:
>
>
>
> Errors may occur during processing of an EXTENDED COPY command before GOOD
> status is returned because the IMMED bit is set to one or the first segment
> descriptor is processed. These errors include CRC or parity errors while
> transferring the EXTENDED COPY command, invalid parameters in the CDB or
> parameter data, invalid segment descriptors, and inability of the copy
> manager to continue operating. In the event of such an exception condition,
> the copy manager shall:
>
> a) terminate the EXTENDED COPY command with CHECK CONDITION status;
>
> b) set the sense key to a value that describes the exception condition
> (i.e., not COPY ABORTED); and
>
> c) not return a value in the INFORMATION field (see 4.5.4).
>
>
>
> and section 5.16.7.4 states:
>
>
>
> Errors may occur after the copy manager has begun processing segment
> descriptors or GOOD status has been returned because the IMMED bit was set
> to one. These errors include invalid parameters in segment descriptors,
> invalid segment descriptors, unavailable CSCDs referenced by CSCD
> descriptors, inability of the copy manager to continue operating, and
> errors reported by a CSCD. If the copy manager receives CHECK CONDITION
> status from a CSCD, then it shall recover the sense data associated with
> the exception condition and clear any ACA condition associated with the
> CHECK CONDITION status.
>
>
>
> In both sections, "invalid segment descriptors" is mentioned -- does this
> imply that a copy manager can either validate all segment descriptors
> before processing the first segment descriptor or validate segment
> descriptors as they are processed.  I'm also confused what "processing
> segment descriptors" means, since it apparently determines whether the
> sense key is set to COPY ABORTED or not.  Does processing a segment
> descriptor mean that the copy manager has begun to issue commands to one or
> more CSCDs?
>
>
>
> For example, how should a copy manager report the following errors?
>
> 1) A segment descriptor references a destination CSCD that is write
> protected.
>
> 2) A segment descriptor attempts to copy a range of blocks that exceeds
> the maximum LBA of either the source or destination CSCD.
>
>
>
> If the copy manager is able to validate all segment descriptors before
> starting any copy operations, then it seems Section 5.16.7.3 applies, and
> the copy manager shall not set the sense key to COPY ABORTED.  However
> reporting ILLEGAL REQUEST, LOGICAL BLOCK ADDRESS OUT OF RANGE doesn't
> specify which CSCD's maximum LBA was exceeded.
>
>
>
> Thanks!
>
>
>
> --
> *Paul Hughes**
> Senior Software Engineer, SolidFire, Inc.*
> e: phughes at solidfire.com
> *Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play&gt;
> ™*
>



More information about the T10 mailing list