FCP-2 recovery problem

Robert Snively rsnively at Brocade.COM
Tue Jun 27 14:22:03 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at Brocade.COM>
*
Matt,

Seems you and I disagree on this issue.  The upper layer is the 
only layer that knows what the ordering requirements are.  In
addition, the ordering requirements are on an application/logical
unit basis, not an application/target basis.  While an upper layer
may not choose to set the CRN itself, it must label the work unit
as requiring a CRN by some method or other, allowing other layers of
the driver to perform that activity.  Those work units (Command
Control Block or whatever the particular driver calls them) that
do not require CRN or require no CRN must similarly not have such
a label.

One of the reasons you (and for that matter I) have never seen such
drivers is that we have never had CRNs until this year and neither
of us work in Storage Technology or in IBM's tape division.  They
may never have seen them either, but they are probably working on
creating them if not.

Bob

>  -----Original Message-----
>  From: Matt Wakeley [mailto:matt_wakeley at agilent.com]
>  Sent: Tuesday, June 27, 2000 10:02 AM
>  To: Robert Snively; T10 at t10.org; 'FC Reflector'
>  Subject: Re: FCP-2 recovery problem
>  
>  
>  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