FCP-2 recovery problem

robbyb at us.ibm.com robbyb at us.ibm.com
Thu Jun 22 07:31:29 PDT 2000

* From the T10 Reflector (t10 at t10.org), posted by:
* robbyb at us.ibm.com

I'm opposed to FCP_CONF due to performance considerations.  Not all chips
handle FCP_CONF automatically.
Even if suport is built into hardware it adds an extra round trip, which
for a device that generally doesn't support queueing
causes significant performance penalties in the bigger SANs.

The Parameter field fix is very easy to implement and does not affect
performance.  I agree that it seems more of
an FC-FS construct than an FCP-2 construct.
Rob Basham
IBM Tapes

* From the T10 Reflector (t10 at t10.org), posted by:
* "Zeitler, Carl" <Carl.Zeitler at compaq.com>
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
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
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

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

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

* 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