SAS under/over flow

Elliott, Robert (Server Storage) Elliott at hp.com
Tue Sep 11 16:23:29 PDT 2007


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
On reads, the initiator port knows how many dwords of read data it
receives.
a) If the target finishes a command with GOOD status but doesn't deliver
all the expected amount of read data (underflow), the initiator port
needs to report the actual length to the application so it does not read
bogus data out of the buffer.  For commands like INQUIRY, it is normal
to specify a large ALLOCATION LENGTH field and only partially fill the
buffer.  For a block device type READ command, this is erroneous
behavior by the target.
b) If the target attempts to send too much read data (overflow), the
initiator port needs to avoid writing beyond the end of the buffer (no
buffer overflow bugs) and ignore subsequent read data frames for the
tag.  The application client is supposed to abort the command (see
sas2r11 section 9.2.5.2 about data offset problems) if it can (the
target might send a RESPONSE frame before it can do so, but the
initiator already knows the command has a problem).
On writes, the target port knows how many dwords of write data it
receives.  
a) If the initiator delivers too little write data (underflow) for an
XFER_RDY, the target waits indefinitely for it to arrive.  The Initiator
Response Timeout will kick in (see 10.2.7.4), yielding CHECK
CONDITION/ABORTED COMMAND/INITIATOR RESPONSE TIMEOUT.
b) If there is too much write data (overflow) for an XFER_RDY, the
target terminates the command with CHECK CONDITION/ABORTED COMMAND/TOO
MUCH WRITE DATA.
This followed the packetized parallel SCSI model rather than the FCP
model to reduce the number of duplicate lengths that complicate error
checking/handling:
1) the length specified by the CDB (sometimes a number of bytes field;
other times a number of blocks field; for a few commands, simply implied
by the command definition)
2) the Data Length field in the command IU  
3) the actual number of bytes transferred
Notice SAS doesn't have RDDATA and WRDATA bits either.	
In FCP-3, T10 struggled a long time with proposals 03-393 and 05-044 to
handle all the possible mismatches between its three lengths and the
RDDATA/WRDATA bits.  If you rely solely on the RESPONSE frame
overflow/underflow information, you will still miss some error cases.
Lack of a Data Length field in the command IU does complicate direct
bridging to a protocol such as FCP or iSCSI that does have such a Data
Length field.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Eddy Quicksall
> Sent: Tuesday, September 11, 2007 4:35 PM
> To: t10 at t10.org
> Subject: SAS under/over flow
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Eddy Quicksall" <Quicksall_iSCSI at bellsouth.net>
> *
> How does the initiator determine underflow or overflow? I 
> don't see it in the response frame. 
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list