FCP-2: Reasons why CRN must be target based (not lun based)
Dave.Baldwin at emulex.com
Tue Jul 18 16:11:57 PDT 2000
* From the T10 Reflector (t10 at t10.org), posted by:
* "Baldwin, Dave" <Dave.Baldwin at emulex.com>
Command frames should not be dropped often, but they will be dropped occasionally. When a
command is dropped, every command to the target would have to be held up by the target until
it can figure out what LUN the command was destined for. Your suggestion of a new ELS would
make this happen quicker, but even with this addition, if the ELS handling is done in the
device driver, it could take 100s of milliseconds.
Once the target's queue fills up, it can't even return queue fulls because the commands need
to execute in order. The only alternative is to drop further commands on the floor. This
causes even bigger recovery problems, now on multiple LUNs. It looks very ugly to me...
FC to SCSI bridges will feel the pain, as all the SCSI devices are treated as LUNs from the
Fibre Channel Initiator's perspective. The FCP-2 retry bit is defined in the PRLI command
which applies to all the LUNs behind an N_Port. I'm also sure there are multi-LUN tape
devices being developed. There may be multi-LUN tape/disk devices being developed (although if
I were doing the development I would put the tape and disk devices on separate D_IDs).
If any OS vendors bite off on the task of implementing queued tape commands (which I don't see
happening soon), the least of their worries would be putting in CRN. The error recovery is
extremely complex. Passing the CRN in a structure down to the HBA driver level is a trivial
task. If a customer is OK with running parallel SCSI, then they don't need to even run FCP-2.
Just recover commands on an exchange basis in Fibre Channel and you get the same behavior. I
believe any OS vendor that takes the effort to implement queued tape commands would also see
the benefit in supplying a CRN for FCP-2 recovery.
Matt Wakeley wrote:
> "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.
> 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