FCP-2 recovery problem
Carl.Zeitler at COMPAQ.com
Thu Jun 22 04:46:25 PDT 2000
* 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 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?
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
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
* 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