FCP-2 recovery problem

David Ford dford at orca.com
Thu Jun 22 13:14:43 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* David Ford <dford at orca.com>
*
At 03:09 PM 6/22/00 , Zeitler, Carl wrote:
>* From the T10 Reflector (t10 at t10.org), posted by:
>* "Zeitler, Carl" <Carl.Zeitler at compaq.com>
>*
>OK, I agree for long links it could have a performance impact.
>
>Rather than using a 4 byte handle in the Parameter field in the header, the
>same thing could be done with a 1 BIT handle in the FCP_Cmd IU, where the
>bit would flip between 0 and 1 for the same OX_ID.  This 1 BIT Handle would
>then be carried in REC/SRR as previously described.  But this would confine
>the change to FCP without involving FS and all the broad implications that
>implies. This is in keeping with FC_VI which carries a handle in its
>payload, rather than the
>header.

Carl,

Actually, FC-VI handles are carried in a Device_Header and not the payload.

-- Dave


>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: robbyb at us.ibm.com [mailto:robbyb at us.ibm.com]
>Sent: Thursday, June 22, 2000 9:31 AM
>To: Zeitler, Carl; T10 at t10.org
>Subject: RE: FCP-2 recovery problem
>
>
>
>
>Carl,
>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.
>Regards,
>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
>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
>
>
>*
>* 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