CRNs and task management

Dave Peterson dap at
Thu Jun 25 15:38:54 PDT 1998

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* Dave Peterson <dap at>
Bob Snively wrote:

> >
> > The scenario you describe seems to involve some complicated housekeeping. In
> > any event, attaching CRNs to task management functions also has the benefit
> > of allowing a single error recovery scheme to be used for all FCP
> > transactions.
> Folks,
> I really want the CRNs to be application to device server, not
> host adapter to FC queue.  That means that I will not necessarily use
> a single all-knowing driver program to put these values on the
> commands.  It further means that applications or higher level drivers
> may sequence the commands for a particular drive.  It may also mean
> that the source of the task management functions may not have knowledge
> of the CRNs being sourced by the driver of the SCSI functions.
> It gives me the further advantage of verifying order through the
> driver queues and through the host adapter.

Sounds like a bug to me if driver queues and host adapters are reordering
commands.I could see some software aware of the device type reordering commands
but not
driver queues or a host adapter and especially not for tape devices.

In thinking about alternate pathing for a moment I could see a need for
CRN at the application client level (depending on the implementation).

And I strongly agree with the statement:
"If we really want to create  FC transport level sequencing,
we should crack down on the sloppy use of these values".
A ULP level function could then be used for other reasons (i.e alternate
But all I heard was objections so a CRN is the next best thing (at this time:).

In regards to CRN and task management functions I do like the idea of a single
error recovery scheme for all FCP transactions though.

Have a great weekend (I'm going fishin).

> While I could theoretically create an architecture that does lock
> Task Management functions in sequence with SCSI commands, I want the
> flexibility to create a different architecture as well.
> The most effective way I know to accomplish this is to sequence the
> the SCSI commands and leave the sequencing of the Task Management functions
> to synchronized ordering.
> This is what was decided at the meeting and I am still convinced that it
> is the right way to do things.
> Note that you already have three levels of Fibre Channel level sequencing,
> Exchange ID, Sequence ID, and Sequence Count.  If we really want to create
> FC transport level sequencing, we should crack down on the sloppy use of
> these values, not create a ULP level function to do the same thing.

> Bob

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list