Data Out residual overflow/underflow handling

Gerry Houlder gerry.houlder at
Fri Sep 21 10:11:13 PDT 2012

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

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 harm".
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 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.
> Are there any other alternatives?
> Thanks,
> Paul

More information about the T10 mailing list