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

From: Paul Hughes <[email-masked]>
Date: Thu, 20 Sep 2012 21:21:32 -0600

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

---

From: "Knight, Frederick" <[email-masked]>
Date: Fri, 21 Sep 2012 14:00:21 +0000

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: [email-masked]<mailto:[email-masked]> (T10 defines the SCSI architecture and writes the various SCSI command standards).

                Fred Knight

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hughes
Sent: Thursday, September 20, 2012 11:22 PM
To: [email-masked]
Subject: [Ips] Data Out residual overflow/underflow handling

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?

Thanks,
Paul

---

From: Paul Hughes <[email-masked]>
Date: Fri, 21 Sep 2012 09:45:16 -0600

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 <
[email-masked]> 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).****
>
> ** **
>
> ****
> ** **
> 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: [email-masked] (T10 defines the SCSI architecture and writes the
> various SCSI command standards).****
>
> ** **
>
>                 Fred Knight****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Paul
> Hughes
> *Sent:* Thursday, September 20, 2012 11:22 PM
> *To:* [email-masked]
> *Subject:* [Ips] Data Out residual overflow/underflow handling****
>
> ** **
>
> Not sure if this is the best place to ask, but here goes...****
>
> ** **
>
> following scenario:****
> ** **
> is formatted to 4KB block size.****
>
> ** **
>
> Here are my thoughts:****
>
> ** **
>
> confused initiator to essentially corrupt data on the logical unit.****
>
> ** **
>
> count of 512?****
> ** **
> Are there any other alternatives?****
>
> ** **
>
> Thanks,****
>
> Paul****
>
> ** **
>
> ** **
>
> ** **
>