Re: [Ips] Data Out residual overflow/underflow handling

[Paul Hughes <[e-mail]>]

Thanks for the detailed response Fred.  I will post this question to the
T10 reflector to see what they have to say, but thought I'd start here.

One follow up question:  If the initiator didn't send any immediate data
(the iSCSI Command Request PDU EDTL=512, but the data segment length is 0
and the Final bit is set), would the target have the same options?  I
believe the only difference would be the Sense Key that is reported
(Illegal Request if no immediate data was transferred, and Aborted Command
if immediate data was transferred).  I expect the residual reporting would
remain the same regardless of whether any data was transferred or not,
correct?

Thanks,
Paul



On Fri, Sep 21, 2012 at 8:00 AM, Knight, Frederick <
[e-mail]> wrote:

>  You have a couple of choices.****
>
> ** **
>
> For example, SBC makes several statements about non-deterministic outcomes
> such as:****
>
> ** **
>
> The device server may terminate the command before processing or after the
> device server has transferred some or all of the data. (walking off the
> end of the device)****
>
> ** **
>
> The degree that the medium is altered by this command is vendor specific.(The format command)
> ****
>
> ** **
>
> But those aren’t directly related.  However, as you mention, FCP provides
> the following 3 choice:****
>
> If the command requested that data beyond the length specified by the FCP_DL
> field be transferred, then the device server shall set the FCP_RESID_OVER bit
> (see 9.5.8) to one in the FCP_RSP IU and:****
>
> **a)       **process the command normally except that data beyond the FCP_DL
> count shall not be requested or transferred;****
>
> **b)       **transfer no data and return CHECK CONDITION status with the
> sense key set to ILLEGAL REQUEST and the additional sense code set to
> INVALID FIELD IN COMMAND INFORMATION UNIT; or****
>
> **c)           **may transfer data and return CHECK CONDITION status with
> the sense key set to ABORTED COMMAND and the additional sense code set to
> INVALID FIELD IN COMMAND INFORMATION UNIT.****
>
> ** **
>
> Case a) and c) allow the media to be modified.  Case b) implies no media
> alteration (since no data is transferred).  Choice b) and c) include SCSI
> layer sense data, but choice a) includes only an FCP layer notification (no
> SCSI sense data, so a broken host (one that ignores residual unless a check
> condition exists) will assume success).****
>
> ** **
>
> RFC5048 says:****
>
>    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).****
>
> ** **
>
> SPDTL = the SCSI layer transfer size; EDTL = the iSCSI layer transfer size.
> ****
>
> ** **
>
> Since the SCSI layer transfer size in your example is 4096, and the iSCSI
> layer transfer size is 512, then you must report the OVERFLOW as defined in
> RFC3720 (bit 5 in the flags field of the SCSI response PDU).  I couldn’t
> quickly find any suggestions in RFC3720/5048 for sense data, so I’d suggest
> you go with choice b) or c) that FCP is using (I’d suggest staying away
> from choice a) since it has bad possibilities).  At least that is
> something hosts should already be familiar with.****
>
> ** **
>
> The other list you might use for these kinds of questions is the SCSI
> reflector: [e-mail] (T10 defines the SCSI architecture and writes the
> various SCSI command standards).****
>
> ** **
>
>                 Fred Knight****
>
> ** **
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Paul
> Hughes
> *Sent:* Thursday, September 20, 2012 11:22 PM
> *To:* [e-mail]
> *Subject:* [Ips] Data Out residual overflow/underflow handling****
>
> ** **
>
> Not sure if this is the best place to ask, but here goes...****
>
> ** **
>
> How should an iSCSI target (SCSI direct-access block device) handle the
> following scenario:****
>
> ** **
>
> An initiator issues an iSCSI Command Request PDU containing a SCSI Write
> CDB with a transfer length of 1 block.  The iSCSI Command Request PDU has
> an Expected Data Transfer Length of 512 bytes, a Data Segment Length of 512
> bytes (immediate data), and the Final flag is set.  This would be a
> perfectly normal single block write, except that the target's logical unit
> is formatted with 4096-byte block size.  So it appears the initiator is
> confused and sending a single 512-byte block write to a logical unit that
> is formatted to 4KB block size.****
>
> ** **
>
> Here are my thoughts:****
>
> ** **
>
> 1) The target could write the 512 bytes of immediate data plus 3584 bytes
> (4096 minus 512) of whatever it wants to the media, and then send an iSCSI
> Command Response PDU with SCSI status of Good and reporting an Overflow
> with a residual count of 3584.  This seems to be the most correct way of
> handling this scenario, but it seems dangerous to allow an apparently
> confused initiator to essentially corrupt data on the logical unit.****
>
> ** **
>
> 2) The target could send an iSCSI Command Response PDU with SCSI status of
> Check Condition, with sense data of Aborted Command, Invalid Field in
> Command Information Unit (0x0E03).  This sense code is apparently intended
> for FCP (I found it mentioned in FCP-4) but it seems appropriate in this
> case.  Assuming the target can fail the SCSI Write command this way (or
> some other way), should the target also report an Underflow with a residual
> count of 512?****
>
> ** **
>
> Are there any other alternatives?****
>
> ** **
>
> Thanks,****
>
> Paul****
>
> ** **
>
> ** **
>
> ** **
>