SMC-3 Read Element Status - Incomplete descriptors

[Rose, Roger]

* From the T10 Reflector (t10 at t10.org), posted by:
* "Rose, Roger" <Rrose at exabyte.com>
*
As far as prohibiting partial element descriptors, the Request Volume
Element Address works the same as Read Element Status.
In this case, the prohibition on partial element descriptors is
important, since unreturned element descriptors remain queued for the
next command.  This would be difficult to implement if partial
descriptors were returned. 
-roger rose
 Exabyte Corp.
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Gerry.Houlder at seagate.com
> Sent: Tuesday, September 26, 2006 3:50 PM
> To: t10 at t10.org
> Subject: RE: SMC-3 Read Element Status - Incomplete descriptors
> 
> * 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
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org