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.
Content-Type: text/plain; charset=us-ascii
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
nexus (i.e. not I_T nexus).
"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
> field by one bit. Now instead of roll over at 64k, you roll over at
> However, in many implementations I'm familiar with the OX_ID range used
> 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
> exchange. Most FC chips don't have resources to support 64K exchanges
> d_id and thus the real range for OX_ID is much smaller. (We'd be guilty
> 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
> about OX_ID assignments is that because it is an index into chip
> the management of it is often in a very low layer of the driver that has
> 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
> 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
> value to be placed in the header (built by a lower layer). I'd rather
> the new data in the payload that is built by the same layer that
> what is going on.
> ********* here is my proposal **********
> For any command that can't be simply aborted and retried (i.e. not
> etc.) use a non-zero CRN value. Define the reserved byte in the REC
> 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
> ACC or RJT the command.
> This is basically the same thing as Dave's proposal with the following
> - 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
> for command delivery ordering. There it not a need to queue larger than
> for sequential devices.
> Charles Binford
> LSI Logic Storage Systems
> (316) 636-8566
Content-Type: text/x-vcard; charset=us-ascii; name="dap.vcf"
Content-Disposition: ATTACHMENT; filename="dap.vcf"
Content-Description: Card for David A. Peterson
org:StorageTek;Minnesota Research and Development Center
email;internet:dap at network.com
fn:David A. Peterson
More information about the T10