FCP-2: Reasons why CRN must be target based (not lun based)
Matt Wakeley
matt_wakeley at agilent.com
Tue Jul 18 12:36:11 PDT 2000
* From the T10 Reflector (t10 at t10.org), posted by:
* "Matt Wakeley" <matt_wakeley at agilent.com>
*
"Baldwin, Dave" wrote:
> Bob,
>
> Although Matt brings up some very good points, I believe it would be detrimental to
> Fibre Channel if we change the CRN to be target based. When a target has devices (disk
> or tape) that are not being utilized while a single tape device is going through error
> recovery for potentially a lengthy amount of time, one could make an argument about
> using a non-Fibre Channel interface. Fibre Channel to SCSI bridges would definitely
> feel the pain. If we want to maintain our high performance image, we can't change CRN.
How often is a command frame going to get dropped? If frames are being dropped
frequently, then I question the "high performanceness" of the FC connection. If
recovering commands quickly is required, we could invent a new ELS that the target will
send to the initiator when a command is detected to be missing (of course this won't work
in an out of order topology).
How many targets are really going to have both queued and non queued LUs behind it? FC to
SCSI bridges shouldn't feel the pain because every device on the scsi bus should be a
different target.
> Currently, I don't think there are any tape devices running queued commands on a
> released operating system. The Class driver (or equivalent) would have to be beefed up
> to handle the error recovery problems associated with queued tape commands. When the
> Class driver adds this support, we need to require that it also handle the CRN
> appropriately. This is the proper level to handle LUN based parameters.
So, you want to write code into the class driver that is FC specific (to handle CRNs) that
is not required for a SCSI parallel bus (I'll bet <insert major OS vendor name here> is
anxious to sign up for that). Also, when this new class driver comes out, there will be
the need to then modify the port/mini-port drivers to pass this data down.
>
Regards,
Matt Wakeley
*
* 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