FCP-2 recovery problem
Robert Snively
rsnively at Brocade.COM
Tue Jun 27 08:32:43 PDT 2000
* 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
More information about the T10
mailing list