Data Out residual overflow/underflow handling

Black, David david.black at emc.com
Fri Sep 21 12:38:10 PDT 2012


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1209215_f.htm">HTML-formatted message</a>

Yes, and (IMHO) they're reasonable assumptions - initiators generally do (and
should) issue a READ CAPACITY, either (10) or (16), as part of discovery, and
that command returns target blocksize info.
Thanks,
--David
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ken Craig
Sent: Friday, September 21, 2012 2:39 PM
To: 'Paul Hughes'; 'Gerry Houlder'
Cc: 't10 at t10.org'
Subject: RE: Data Out residual overflow/underflow handling
Are assumptions being made here that the Initiator and Target have executed
enough Device Discovery to determine that the Target is formatted with 4K
blocks and that the Host/Initiator supports a Target with a 4K block size?
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Paul Hughes
Sent: Friday, September 21, 2012 11:12 AM
To: Gerry Houlder
Cc: t10 at t10.org
Subject: Re: Data Out residual overflow/underflow handling
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