Data Out residual overflow/underflow handling

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


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1209213_f.htm">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 solidfire.com> 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 seagate.com
> > 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
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 solidfire.com>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