Data Out residual overflow/underflow handling

Gerry Houlder gerry.houlder at
Fri Sep 21 11:22:40 PDT 2012

Formatted message: <a href="">HTML-formatted message</a>

I would make the same choice for read. if you want to read a logical block
you need to read it all, not just part of it. SCSI is called a 'block
oriented" interface.
On Fri, Sep 21, 2012 at 1:12 PM, Paul Hughes <phughes at> wrote:
> Thanks Gerry.  If the SCSI command was a read instead of a write, would
> you also return Check Condition status, or would you return 512 bytes of
> data and Good status (plus report the residual overflow)?  I'm considering
> the latter, which would basically make the logical unit a read-only device
> for initiators that may be confused.
> Paul
> On Fri, Sep 21, 2012 at 11:11 AM, Gerry Houlder <gerry.houlder at
> > wrote:
>> Definitely go for case 2 (CHECK CONDITION status with appropriate sense
>> bytes). Writing dummy data to areas of user data without explicit command
>> of the host is asking for big trouble. Mismatches between data transfer
>> length required by the SCSI command bytes and the transfer length in other
>> fields of the command PDU are indications of great confusion by the host
>> such host commands should be considered insane and should not be obeyed.
>> The first imperative of a storage peripheral should be "first, do no
>> Another case similar to case 1 that you ALSO SHOULD NOT CONSIDER is to
>> require the target to merge the 512 bytes into the first 512 bytes of the
>> LBA and retain the existing data for the rest of the LBA (turning the
>> operation into a read-modify-write operation). This is more reasonable
>> (than the dummy data choice) in terms of respecting the integrity of
>> existing user data but still likely to end up as "doing the wrong thing".
>> On Fri, Sep 21, 2012 at 11:02 AM, Paul Hughes
<phughes at>wrote:
>>> I recently posed this question to the IETF's IP Storage mailing list
>>> (iSCSI), but thought I'd get some opinions from T10 as well.
>>> 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
>>> bytes (immediate data), and the Final flag is set.	This would be a
>>> perfectly normal single block write, except that the target's logical
>>> 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
>>> 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
>>> 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
>>> for FCP (I found it mentioned in FCP-4) but it seems appropriate in this
>>> case.
>>> Are there any other alternatives?
>>> Thanks,
>>> Paul

More information about the T10 mailing list