FCP-2 recovery problem

Matt Wakeley matt_wakeley at agilent.com
Tue Jun 27 10:02:10 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* Matt Wakeley <matt_wakeley at agilent.com>
*
Robert Snively wrote:

> * 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).

As long as we're talking basics, I'd like to see an existing SCSI driver that
will pass through a CRN value from a (tape) application.  Or, a SCSI driver
(example: NT) that generates CRN values that it passes through the mini-port
driver to the FCP driver.  The end result is, that this CRN stuff will have to
be generated and maintained in the FCP driver.  And due to the proper use of
protocol layering, the FCP layer has no knowledge of LUs.  It's job is simply
to deliver commands from the initiator to the target.  Therefore, the CRN must
be associated with the whole target, not the LUs behind the target.

Matt Wakeley
Agilent Technologies

*
* 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