End-to-end logical block guard checking question

Sheffield, Robert L robert.l.sheffield at intel.com
Fri Jan 23 12:09:58 PST 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Robert L" <robert.l.sheffield at intel.com>
*
Ed, I think you're on to something.

In the SAM-3 section on Service Delivery Subsystem there's a diagram
showing the
Transport layer sitting between the SCSI Application Layer and the
Interconnect Layer (a.k.a. Service Delivery Subsystem). Looking at the
Transport Layer services as defined, there's no requirement even for the
Transport Layer to have any notion of data-blocks. SAM-3 leaves it up to
each specific transport protocol to define the interface to the
Interconnect Layer, and acknowledges that even the Transport Layer
Services can be done differently as long as it represents the same
capability. I think all we can safely say is that our definition of Data
Protection capability cannot presume anything in the transport layer or
below has the capability to generate or verify Data Integrity fields.
Logically, therefore, the responsibility rests with the Application
Layer. Question - does the Application Layer ever see blocks out of
order, or is it incumbent upon the transport layer to reassemble the
data in the proper order before handing it back to the transport layer?
If it's the latter, then indeed the statement about blocks being
transmitted out of order is meaningless.

Bob

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Edward
A. Gardner
Sent: Friday, January 23, 2004 10:58 AM
To: t10 at t10.org
Subject: Re: End-to-end logical block guard checking question


* From the T10 Reflector (t10 at t10.org), posted by:
* "Edward A. Gardner" <eag at ophidian.com>
*
At 07:54 23-01-2004, George Penokie wrote:

>In the protection information description in SBC-2 section 4.5.1 
>Protection information overview the following statement is made:
>
>If the logical unit is formatted with protection information and the
EMDP 
>bit is set to one in the Disconnect-Reconnect mode page (see SPC-3),
then 
>checking of the logical block reference tag or the logical block guard 
>within the service delivery subsystem may cause false errors because 
>logical blocks may be transmitted out of order.

That statement has never made any sense to me.  It's no different than 
saying that if EMDP is set to one, then data may be transferred to 
incorrect data buffer offsets because logical blocks may be transmitted
out 
of order.

Out of order transfers are clearly more complicated than in order 
transfers.  Any implementation that allows EMDP to be set to one must 
account for that.  It must account for it both when transferring to/from
a 
data buffer and when checking protection information.

I suggest we remove that statement, as it serves no purpose.  It assumes
a 
particular implementation, one that only implements in order transfers,
and 
observes that it will break if presented with out of order 
transfers.  Duhhh!  If we were to correct it to be implementation
neutral, 
it would amount to saying that protection checking must be implemented 
correctly or it won't work.  Not exactly a useful statement.


Incidentally, the statements that "protection information ... may be 
checked by any object along the I_T_L nexus" (first paragraph 4.5.1) and

"checking ... within the service delivery subsystem" (paragraph George 
quoted) have some problems.  Checking protection information requires 
knowledge of the block size to determine where the protection
information 
is located.  But the service delivery subsystem is unaware of the block 
size.  Only the application layer knows the block size (according the 
SAM-n), therefore only the application layer can check protection
information.




Edward A. Gardner               eag at ophidian dot com
Ophidian Designs                719 593-8866 voice
1262 Hofstead Terrace           719 210-7200 cell
Colorado Springs, CO  80907

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