FCP-2 recovery problem

Baldwin, Dave Dave.Baldwin at emulex.com
Thu Jun 22 12:10:12 PDT 2000

* From the T10 Reflector (t10 at t10.org), posted by:
* "Baldwin, Dave" <Dave.Baldwin at emulex.com>

I would think we might want to add the parameter field definition into the REC
description in FC-FS (although this is not absolutely necessary). Everything
else should go in FCP-2. I don't feel this behavior should be extended to all
FC-4s, since the handle is acquired through an FCP command frame. If you have
another proposal to extend this to all FC4s, I would be willing to look at it.

I have been told by at least one FC Tape vendor that the FCP_CONF overhead is
too expensive, and they couldn't live with the performance consequences.
Additionally, I don't see how FCP_CONF solves this issue without confirming the
FCP_CONF with either another IU or by using REC (unless we put lengthy timeouts
in before reusing an OX_ID).

I feel my proposal is the best solution to this issue, maintaining good
performance without requiring additional sequence delays and without tying up
OX_ID resources for long periods of time.

Best regards,
Dave Baldwin

"Zeitler, Carl" wrote:

> Dave, it would seem to me that extending the definition of the Parameter
> field should be handled in FC-FS, not FCP-2.  This is a more global issue in
> my mind and would apply to all FC-4s, not just FCP-2.
> I understand the recovery problem that you have described and it needs to be
> addressed.  Are you opposed to the use of FCP_CONF as part of the solution
> for performance reasons? Or just that you can't see how the use of FCP_CONF
> solves the problem?
> Regards, Carl
> Carl Zeitler
> Compaq Computer Corporation
> MS 150801, 20555 SH249, Houston, TX 77070
> Phone:281-518-5258 Fax: 281-514-5270
> E-Mail: Carl.Zeitler at compaq.com
> -----Original Message-----
> From: Baldwin, Dave [mailto:Dave.Baldwin at emulex.com]
> Sent: Tuesday, June 20, 2000 8:42 PM
> To: Fibre Reflector; T10 Reflector
> Cc: Robert Snively (Brocade)
> Subject: FCP-2 recovery problem
> After considering several solutions to this issue, I have come up with
> the attached proposal to solve the problem. Since Emulex is not a T10
> member, I am not sure where to put the proposal, or how to number it.
> Any guidance in this area would be appreciated.
> There are other potential solutions to the problem, but they are
> generally more complex and cause performance degradation. Matt's
> suggestion to use FCP_CONF and then send REC to make sure the FCP_CONF
> made it to the target would have to be used on all non-write commands,
> thus degrading performance (but it does work).
> There are OX_ID games one could play, but they would require lengthy
> delays in releasing resources, or complex queuing behaviors that will
> cause problems or performance degradation  in some  implementations.
> Here is an example of a hole one could hit trying to control OX_ID use:
> Behavior: Control the OX_ID such that there are never two identical
> consecutive OX_IDs sent to an FCP-2 LUN.
> Flaw: This behavior would fail in a multi-LUN FCP-2 target. Here is one
> scenario:
> Command1 -----> OX_ID=1, LUN=0
> OX_ID=1     <----- Response1
> (Send 64k other commands to other targets in less than 2 seconds)
> Command2 ------> OX_ID=1, LUN=1   X (command dropped)
> REC             -------> OX_ID=1, RX_ID=0xFFFF
> Good response sent <------- ACC
> The Initiator sent the REC to check on Command2 to LUN=1. The target
> sent an ACC with information about Command1 to LUN=0. This leads to
> invalid recovery. Controlling OX_ID reuse to a LUN is not sufficient to
> solve this problem.
> Please review the attached proposal and send your comments back to the
> reflector.
> Best regards,
> Dave Baldwin
> Emulex Corporation

* 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