Clarification on SCSI presented data length for residual overflow/underflow determination

Paul Hughes phughes at solidfire.com
Sat Jun 14 07:45:00 PDT 2014


Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1406141_nameless-2976-2-1.html">nameless-2976-2-1.html</a>

Thanks David, that is the clarification I was looking for. It was not clear
to me whether "data transfer" meant a transfer of data between the
initiator port and the target port or between the iSCSI layer and the SCSI
layer, though I was thinking it was the latter.
The reason for my question is that we've discovered open-source software
that essentially assumes a DataIn command that completes with a residual
count of zero has completed successfully, thus ignoring SCSI check
condition status for UA and causing data corruption. This behavior made me
question whether the residual count should have been non-zero, to notify
the initiator that no data was transferred to the application client.  I
would not be surprised if other software has a similar misunderstanding
about the meaning of the residual count, but hopefully it wouldn't ignore
the SCSI status.
On Sat, Jun 14, 2014 at 7:51 AM, Black, David <david.black at emc.com> wrote:
> Paul,
>
>
>
> This question needs a scenario in which a data transfer is actually
> attempted ... here’s some key text from RFC 7143, the current reference
for
> iSCSI:
>
>
>
> 11.4.5.2.  Residuals Concepts Overview
>
>
>
>    "SCSI-Presented Data Transfer Length (SPDTL)" is the term this
>
>    document uses (see Section 2.2 for definition) to represent the
>
>    aggregate data length that the target SCSI layer attempts to transfer
>
>    using the local iSCSI layer for a task.
>
>
>
> The words “the target SCSI layer attempts to transfer” are important
here
> - the whole point of residuals is to report differences between the size of
> the data transfer specified by a SCSI command and the amount of data that
> is actually transferred when a transfer is attempted for that command
> (e.g., command specifies 8k of data, but the data transfer stops at 4k or
> tries to transfer 12k).
>
>
>
> Turning to the new example:
>
>
>
> > , if a single block write command is enabled and begins processing but
> then fails with Check Condition status
>
> > (e.g. Illegal Request, Invalid Field in CDB sense data),
>
>
>
> The actual error matters.
>
>
>
> For an ILLEGAL REQUEST error for a simple command like read or write, the
> target does not attempt to transfer any data, so SPDTL is a meaningless
> concept.  The O and U bits should be set to zero in the response in this
> case, as the initiator won’t be doing anything with them; the initiator
> should see the ILLEGAL REQUEST error and infer that nothing happened at the
> target.
>
>
>
> As is the case for a UA, there is no target attempt to transfer **at the
> SCSI layer**.  If iSCSI immediate data was sent, the target iSCSI layer
> bit-buckets that immediate data because the target SCSI layer never asked
> for it.  The distinction between the SCSI layer and iSCSI layer is very
> important here.
>
>
>
> Thanks,
> --David
>
>
>
> *From:* Paul Hughes [mailto:phughes at solidfire.com]
> *Sent:* Friday, June 13, 2014 12:40 PM
> *To:* Black, David
> *Cc:* t10 at t10.org
> *Subject:* Re: Clarification on SCSI presented data length for residual
> overflow/underflow determination
>
>
>
> Thanks for the response, but I'm not sure if you're implying there is no
> residual because the command was never processed, and I don't see where RFC
> 3720 or RFC 5048 state that no residual should be reported when a command
> is not processed.  Section 10.4.1 of RFC 3720 states:
>
>
>
> bit 5 - (O) set for Residual Overflow. In this case, the Residual
>
> Count indicates the number of bytes that were not transferred
>
> because the initiator’s Expected Data Transfer Length was not
>
> sufficient. For a bidirectional operation, the Residual Count
>
> contains the residual for the write operation.
>
>
>
> bit 6 - (U) set for Residual Underflow. In this case, the Residual
>
> Count indicates the number of bytes that were not transferred out
>
> of the number of bytes that were expected to be transferred. For
>
> a bidirectional operation, the Residual Count contains the
>
> residual for the write operation.
>
>
>
> Ignoring the unit attention scenario for now, if a single block write
> command is enabled and begins processing but then fails with Check
> Condition status (e.g. Illegal Request, Invalid Field in CDB sense data),
> would the SPDTL be zero (resulting in a residual underflow of 512 bytes)
> regardless of whether immediate data was transferred with the write
> command, or would the SPDTL be 512 if 512-bytes of immediate data were
> transferred (resulting in no residual underflow/overflow being reported)?
>
>
>
> On Thu, Jun 12, 2014 at 9:04 PM, Black, David <david.black at emc.com> wrote:
>
> Paul,
>
>
>
> Well, the command has not actually been processed by the device server in
>
> the example in your email:
>
>
>
> > For example, the iSCSI layer receives a SCSI command PDU containing a
> CDB for a write of
>
> > a single 512-byte block and an EDTL of 512, and then calls into the SCSI
> layer to process the
>
> > command.  If the SCSI layer completes the command with SCSI Check
> Condition status due
>
> > to a unit attention condition,
>
>
>
> Unit attention (UA) processing occurs when the command is enabled, but
> before
>
> the command is actually processed - see item e) at the end of 5.14.1 in
> SAM-5.
>
>
>
> In this case, I would expect both the U and O bits the iSCSI SCSI Response
>
> PDU to be clear, so neither underrun nor overrun is reported.
>
>
>
> Initiator (application client) code is responsible for understanding that
> UA
>
> delivery occurs before any command processing and hence has to retry any
>
> command that reports a UA.
>
>
>
> Thanks,
> --David
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Paul
> Hughes
> *Sent:* Thursday, June 12, 2014 6:31 PM
> *To:* t10 at t10.org
> *Subject:* Clarification on SCSI presented data length for residual
> overflow/underflow determination
>
>
>
> For iSCSI, RFC 5048 states:
>
>
>
> 2.1.	Definitions
>
>
>
>    SCSI-Presented Data Transfer Length (SPDTL)
>
>	SPDTL is the aggregate data length of the data that the SCSI layer
>
>	logically "presents" to the iSCSI layer for a Data-In or Data-Out
>
>	transfer in the context of a SCSI task.  For a bidirectional task,
>
>	there are two SPDTL values -- one for Data-In and one for Data-
>
>	Out.  Note that the notion of "presenting" includes immediate data
>
>	per the data transfer model in [SAM2], and excludes overlapping
>
>	data transfers, if any, requested by the SCSI layer.
>
>
>
> 3.1.1.  Overview
>
>
>
>    SCSI-Presented Data Transfer Length (SPDTL) is the term this document
>
>    uses (see Section 1.1 for definition) to represent the aggregate data
>
>    length that the target SCSI layer attempts to transfer using the
>
>    local iSCSI layer for a task.  Expected Data Transfer Length (EDTL)
>
>    is the iSCSI term that represents the length of data that the iSCSI
>
>    layer expects to transfer for a task.  EDTL is specified in the SCSI
>
>    Command PDU.
>
>
>
>    When SPDTL = EDTL for a task, the target iSCSI layer completes the
>
>    task with no residuals.  Whenever SPDTL differs from EDTL for a task,
>
>    that task is said to have a residual.
>
>
>
>    If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the
>
>    SCSI Response PDU as specified in [RFC3720].  The Residual Count MUST
>
>    be set to the numerical value of (SPDTL - EDTL).
>
>
>
>    If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the
>
>    SCSI Response PDU as specified in [RFC3720].  The Residual Count MUST
>
>    be set to the numerical value of (EDTL - SPDTL).
>
>
>
>    Note that the Overflow and Underflow scenarios are independent of
>
>    Data-In and Data-Out.  Either scenario is logically possible in
>
>    either direction of data transfer.
>
>
>
>
>
> Given an example where the iSCSI layer receives a SCSI command PDU
> containing a CDB for a read of a single 512-byte block and an EDTL of 512,
> and then calls into the SCSI layer to process the command.  If the SCSI
> layer completes the command with SCSI Check Condition status due to a unit
> attention condition, would the SPDTL be zero because the SCSI layer never
> attempted to transfer data using the iSCSI layer?  If so, then an underflow
> with residual count of 512 should be signaled, correct?
>
>
>
> I'm not sure what was meant by 'the notion of "presenting" includes
> immediate data' in Section 2.1.  Does this mean that the SPDTL is the same
> regardless of whether immediate data was received or not?
>
>
>
> For example, the iSCSI layer receives a SCSI command PDU containing a CDB
> for a write of a single 512-byte block and an EDTL of 512, and then calls
> into the SCSI layer to process the command.  If the SCSI layer completes
> the command with SCSI Check Condition status due to a unit attention
> condition, would the SPDTL be zero because the SCSI layer never attempted
> to transfer data using the iSCSI layer, or does the SPDTL depend on whether
> immediate data was already transferred in the iSCSI command PDU?
>
>
>
> 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;â„¢*
>
>
>
>
>
> --
> *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;â„¢*
>
-- 
*Paul HughesSenior 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