CRNs and task management
dap at nsco.network.com
Thu Jun 25 15:38:54 PDT 1998
* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Dave Peterson <dap at nsco.network.com>
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.
> 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
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.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com
More information about the T10