FCP-2 recovery problem

[Robert Snively]

* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at Brocade.COM>
*
Let me go back to basics here.

	CRN was not intended as a recovery mechanism.  It was
	intended as an ordering mechanism for a string of commands
	being executed against a single logical unit.  All the 
	queue ordering is executed against a single logical unit.
	The CRN is sourced as a part of the command packet associated
	with a single logical unit (and may even be numbered at
	a relatively high level in the driver stack or in the
application).  

	Task management operations can be used to reset a logical
	unit's expectation of the next CRN, and for that among
	many other reasons, were not placed in the CRN management
	space.

Fully qualified exchange identifier is about as unique a label
for a command as you can get, especially if you choose to disqualify
RX_ID as a participant.  Making it more unique does not resolve
the problem any better.  For those cases where RX_ID was never
exchanged, FCP_CONF still looks like a good way to assure that
it was, thus resolving the original problem.

Bob

>  -----Original Message-----
>  From: Matt Wakeley [mailto:matt_wakeley at agilent.com]
>  Sent: Monday, June 26, 2000 10:40 AM
>  To: T10 at t10.org; 'FC Reflector'
>  Subject: Re: FCP-2 recovery problem
>  
>  
>  * From the T10 Reflector (t10 at t10.org), posted by:
>  * Matt Wakeley <matt_wakeley at agilent.com>
>  *
>  
>  
>  "David A. Peterson" wrote:
>  
>  > Howdy All,
>  > 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
>  > I_T_L
>  > nexus (i.e. not I_T nexus).
>  
>  Having CRN based on I_T_L nexus is exactly the wrong thing 
>  to do.  That would
>  require the lowest level part of the initiator driver to 
>  have knowledge (and
>  storage) for all possible LUs in a target.  Say a target had 
>  10,000 LUs.
>  That's a lot of CRNs the lowest part of the driver would 
>  have to keep track
>  of... plus, how does it know about them?  SCSI is the layer 
>  that performs LU
>  discovery.  See my email titled "FCP-2: Command reference 
>  per LUN????"
>  
>  -Matt
>  
>  
>  
>  *
>  * 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