SAM-3 proposal: ... Sense Data size...

Pat LaVarre LAVARRE at iomega.com
Fri Nov 1 10:56:24 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
The following thread, built offline, concludes:
 
"With a true autosense feature or even a virtual
autosense there is no guidance for this (since the
client doesn't issue Request Sense command), so a
parameter is being proposed in the API description to
cover this so the driver doesn't have to parse the
sense data to figure out how many valid bytes there
really are. It can also keep the driver from
overrunning the actual sense data space provided by
the application client."
 
Is that right?
 
Curiously yours, in awesome ignorance, Pat LaVarre

	-----Original Message----- 
	From: ... 
	Sent: Fri 11/1/2002 10:14 AM 
	To: Pat LaVarre 
	Cc: 
	Subject: RE: SAM-3 proposal: ... Data-In and Sense Data sizes
	


	Its OK if you think this should go to the reflector. The true initiator
	experts (like Ralph) might disagree with my use of terms like driver or
	application (they probably have more specific definitions of these terms
	than I do) but I think the concepts are right on.

	-----Original Message----- 
	From: ... 
	Sent: Fri 11/1/2002 7:17 AM 
	To: Pat LaVarre 
	Cc: 
	Subject: RE: SAM-3 proposal: ... Data-In and Sense Data sizes
	
	


	I meant to reply to the reflector. If I had, maybe it would prevent you 
	from getting duplicate opinions. 

	Yes, it is true that some folks might refer to HBA automatically sending 
	Request Sense as an "autosense" feature. In terms of what the SCSI bus sees 
	(parallel SCSI or whatever) this only differs from "normal sense data 
	recovery" by being slightly faster between the Check Condition status and 
	sending the Request Sense command (presumably the HBA would have faster 
	turnaround than the application client would). 

	The main point is that the clasic Request Sense command includes an 
	allocation length parameter in the CDB that instructs the target to limit 
	the sense data length if more than that amount is available. For the true 
	autosense mechanisms there is no such instruction about what maximum space 
	the initiator has available for receiving sense data. This is why there was 
	some guidance added that initiators should reserve a certain amount of 
	space for sense data to prevent data overruns. I believe the recommendation 
	was for 256 bytes (this is the maximum the Request Sense command could 
	return, so it would surely accomodate all existing implementations) but 
	real initiators may actually use a smaller space since only 18 bytes are 
	actually defined and any extra bytes are vendor unique (the "generic" 
	marketplace will only interpret this many bytes regardless of how many are 
	returned). This could lead to implementation issues about what to do when 
	more bytes are returned than was allocated to the sense data area. 

	The Ralph Weber, et. al. email chain seems to be an offshoot of this. The 
	Allocation Length parameter in Request Sense command also is used by the 
	driver to decide how much data to return to the application client. With a 
	true autosense feature or even a virtual autosense there is no guidance for 
	this (since the client doesn't issue Request Sense command), so a parameter 
	is being proposed in the API description to cover this so the driver 
	doesn't have to parse the sense data to figure out how many valid bytes 
	there really are. It can also keep the driver from overrunning the actual 
	sense data space provided by the application client. 

	So I guess you are right that, for the purpose of this discussion, there is 
	no distinction between true autosense and a virtual autosense. 



	                                                                                                  
	                    "Pat LaVarre"                                                                 
	                    <LAVARRE at iome        To:     ...    
	                    ga.com>              cc:                                                      
	                    No Phone Info        Subject:     RE: SAM-3 proposal: ... Data-In and Sense   
	                    Available            Data sizes                                               
	                                                                                                  
	                    10/31/2002                                                                    
	                    05:13 PM                                                                      
	                                                                                                  
	                                                                                                  




	...: 

	(My mailer tells me you sent this reply person-to-person, not to the 
	reflector?  So I've replied in kind.) 

	What you say makes sense, thank you.  Using your terminology we can say 
	that FireWire has autosense but that Usb, Atapi, and classic (8-bit 
	asynchronous fully-handshaked no-disconnect parallel) Scsi do not. 

	I'm curious to know if you mean to say T10 has somewhere tried to restrict 
	the meaning of the term "autosense" this sharply? 

	I hear people use the term autosense to speak of an op x03 RequestSense 
	that automagically follows a CheckCondition, because of some software layer 
	between the app and the device.  That kind of autosense is unreliable 
	unless each host has a way of locking out all the others, so that the sense 
	data remains available until the autosensing host gets around to asking for 
	it.  Often that kind of autosense exists precisely in order to lock out the 
	other hosts. 

	But I think you're telling me some T10 text would object to using the name 
	"autosense" for those schemes?  Ok fine but then what term should we use 
	for them? 

	Curiously yours, Pat LaVarre 

	     -----Original Message----- 
	     From: ... 
	     Sent: Thu 10/31/2002 3:30 PM 
	     To: Pat LaVarre 
	     Cc: 
	     Subject: RE: SAM-3 proposal: ... Data-In and Sense Data sizes 




	     Autosense is a term that is used todescribe sense data that is 
	     automatically returned as part of the status for a command. Protocols 
	such 
	     as Fibre Channel and packetized parallel SCSI allow for this but 
	     non-packetized parallel SCSI does not. Protocols that do not have 
	autosense 
	     (or have it disabled) must follow a command that ends with Check 
	Condition 
	     status with a Request Sense command to get the sense bytes. Thus 
	autosense 
	     replaces the need for Request Sense command following a Check 
	Condition 
	     status. 

	     Even with autosense, Request Sense may still be useful for retrieving 
	sense 
	     bytes not tied to a Check Condition status. Tapes might have some 
	items 
	     like this but disks generally do not. 




	                         "Pat LaVarre" 
	                         <LAVARRE at iome        To:     <t10 at t10.org> 
	                         ga.com>              cc: 
	                         Sent by:             Subject:     RE: SAM-3 
	proposal: ... Data-In and Sense 
	                         owner-t10 at t10        Data sizes 
	                         .org 
	                         No Phone Info 
	                         Available 

	                         10/31/2002 
	                         03:03 PM 






	     * From the T10 Reflector (t10 at t10.org), posted by: 
	     * "Pat LaVarre" <LAVARRE at iomega.com> 
	     * 
	     Perhaps my ignorance here is irreparably vast ... but transports vary 
	in 
	     how they express autosense? 

	     Sometimes autosense does goes thru as op x03 RequestSense with a 
	cdb[4] 
	     allocationLength: Usb, Atapi, classic Scsi ... though not FireWire. 
	How 
	     transparently that allocationLength passes thru from the app varies: 
	some 
	     transports set it to a fixed number: the numbers x0E, x12, and xFF are 
	     popular when op x12 Inquiry data byte 0 bits x1F = x00 Disk.

*
* 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