SMC-3 Read Element Status - Incomplete descriptors

Gerry.Houlder at seagate.com Gerry.Houlder at seagate.com
Tue Sep 26 14:49:31 PDT 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I recall that there is at least one log page that has similar wording about
not returning partial descriptors. I haven't done all the research to prove
it though, maybe it changed since the last time I read that particular log
page.
	     "Elliott, Robert						   
	     (Server Storage)"						   
	     <Elliott at hp.com>						To 
	     Sent by:		       <t10 at t10.org>			   
	     owner-t10 at t10.org						cc 
	     No Phone Info						   
	     Available						   Subject 
				       RE: SMC-3 Read Element Status -	   
				       Incomplete descriptors		   
	     09/26/2006 03:11						   
	     PM 							   
It would be more in line with other SCSI standards for the device server to
return partial descriptors.  The parameter data is supposed to be the same
(for a specific CDB) regardless of how many bytes are retrieved.
SPC-4's general convention for ALLOCATION LENGTH fields (spc4r06 4.3.4.6)
states that "If the information being transferred to the Data-In Buffer
includes fields containing counts of the number of bytes in some or all of
the data, then the contents of these fields shall not be altered to reflect
the truncation, if any, that results from an insufficient ALLOCATION LENGTH
value, unless the standard that describes the Data-In Buffer format states
otherwise."  The ALLOCATION LENGTH field could be anything from zero to
FF...FFh (based on the size of the field).
The STARTING ELEMENT ADDRESS and NUMBER OF ELEMENTS fields in the READ
ELEMENT STATUS CDB instruct the device server how many descriptors and
which descriptors to create.  The parameter data FIRST ELEMENT ADDRESS
REPORTED, NUMBER OF ELEMENTS AVAILABLE, and BYTE COUNT OF REPORT AVAILABLE
fields are all set by the device server without any regard to the
allocation length - those qualify as the "fields containing counts of the
number of bytes".  Note 6 points out how the application client can figure
out the best ALLOCATION LENGTH to use - try 8 first to read just the header
to examine those fields.  Then, pick an allocation length big enough to
retrieve the data.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott
 From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
 Butt
 Sent: Tuesday, September 26, 2006 1:59 PM
 To: t10 at t10.org
 Subject: SMC-3 Read Element Status - Incomplete descriptors
 SMC-3r02, 6.10.1 READ ELEMENT STATUS introduction, 2nd paragraph on page
 321, reads:
 <<
 The NUMBER OF ELEMENTS field specifies the maximum number of element
 descriptors to be created by the device server for this command. The value
 specified by this field is not the range of element addresses to be
 considered for reporting but rather the number of defined elements to
 report. If the ALLOCATION LENGTH field is not sufficient to transfer all
 the element descriptors, the device server shall transfer all those
 descriptors whose complete contents fit within the allocation field and
 this shall not be considered an error.
 >>
 There has been confusion by at least one vendor about the meaning of
 <<
 If the ALLOCATION LENGTH field is not sufficient to transfer all the
 element descriptors, the device server shall transfer all those
 descriptors whose complete contents fit within the allocation field and
 this shall not be considered an error.
 >>
 It seems obvious that the intent is that only complete descriptors shall
 be returned.  If the data is truncated due to an incomplete descriptor
 this shall not be considered an error.  I propose that this text be
 modified to:
 If the ALLOCATION LENGTH field is not sufficient to transfer all the
 element descriptors, the device server shall transfer all those
 descriptors that completely fit within the allocation field and shall not
 transfer any partial descriptors. This shall not be considered an error.
 Thanks,
 Kevin D. Butt
 SCSI & Fibre Channel Architect, Tape Firmware
 MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
 Tel: 520-799-2869 / 520-799-5280
 Fax: 520-799-2723 (T/L:321)
 Email address: kdbutt at us.ibm.com
 http://www-03.ibm.com/servers/storage/
*
* 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