FCP-2 recovery problem

David A. Peterson dap at storage.network.com
Fri Jun 23 10:28:54 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* "David A. Peterson" <dap at storage.network.com>
*
This is a multi-part message in MIME format.
--------------C3CDD0F37AA6E2D147F9EA93
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Howdy All,
Finally catching up on emails.
Charles proposal is exactly what I was thinking also. In my reading of
the CRN text in FCP-2 today, it does not explicitly state the CRN is
based on the I_T_L nexus, but the EPDC bit is contained in the lun
control mode page, so I guess it is implied. Would be nice to see some
text stating this.

Anyways, I think the proposal would work if the CRN is based on the
I_T_L
nexus (i.e. not I_T nexus).

Dave

"Binford, Charles" wrote:
> 
> *
> * From the fc reflector, posted by:
> * "Binford, Charles" <cbinford at lsil.com>
> *
> Carl, I fail to see how adding one bit does any more than extend the
> OX_ID
> field by one bit.  Now instead of roll over at 64k, you roll over at
> 128k.
> However, in many implementations I'm familiar with the OX_ID range used
> is
> much smaller.  This is because people are using it as designed by the FC
> committee - to be an HW lookup index to the resources associated with
> the
> exchange.  Most FC chips don't have resources to support 64K exchanges
> per
> d_id and thus the real range for OX_ID is much smaller.  (We'd be guilty
> of
> designing a very limiting architecture if the typical implementation was
> actually bumping up against the limitations of the standard.)
> 
> The other point (which is more important to this discussion) I want to
> make
> about OX_ID assignments is that because it is an index into chip
> resources
> the management of it is often in a very low layer of the driver that has
> no
> knowledge of the payload.  The layer building the FCP_CMD payload has no
> clue what OX_ID is going to be assigned, the layer assigning the OX_ID
> has
> no clue about any 'Hermann' bit that may or may not need to be set.
> 
> While I believe Dave Baldwin's solution will work, I also have some
> reservations about it.  Again it is the layering thing.  FC driver
> interfaces would have to be changed to allow the upper layer to specify
> a
> value to be placed in the header (built by a lower layer).  I'd rather
> place
> the new data in the payload that is built by the same layer that
> understands
> what is going on.
> 
> ********* here is my proposal **********
> For any command that can't be simply aborted and retried (i.e. not
> Inquiry,
> etc.) use a non-zero CRN value.  Define the reserved byte in the REC
> payload
> to hold the CRN value if non-zero.  A target receiving an REC with a
> non-zero "CRN" value shall match it and the OX_ID before determining if
> to
> ACC or RJT the command.
> 
> This is basically the same thing as Dave's proposal with the following
> modification:
> - new data in payload instead of header
> - on 8 bits instead of 32
> 
> I'd argue that 8 bits is sufficient for the same reasons it is large
> enough
> for command delivery ordering.  There it not a need to queue larger than
> 255
> for sequential devices.
> 
> Comments??
> 
> Charles Binford
> LSI Logic Storage Systems
> (316) 636-8566
>


--------------C3CDD0F37AA6E2D147F9EA93
Content-Type: text/x-vcard; charset=us-ascii; name="dap.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: ATTACHMENT; filename="dap.vcf"
Content-Description: Card for David A. Peterson

begin:vcard 
n:Peterson;David
tel;cell:612-251-6229
tel;work:763-391-1008
x-mozilla-html:FALSE
org:StorageTek;Minnesota Research and Development Center
adr:;;;;;;
version:2.1
email;internet:dap at network.com
title:Principal Engineer
fn:David A. Peterson
end:vcard

--------------C3CDD0F37AA6E2D147F9EA93--




More information about the T10 mailing list