FCP_CONF/CRN

David A. Peterson dap at nsco.network.com
Mon Jul 27 11:47:24 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "David A. Peterson" <dap at nsco.network.com>
*


Bob Snively wrote:

> Folks,
>
> I thought about this and suggest that you add the following to
> the end of annex D, for CRN.  This is necessary to get through boot,
> particularly to determine if the default or saved parameter value of ECRN is
> equal to 1 or 0.  If you can get it in this rev, it would be a great help.
>
> I think that this also creates the permissive error case that we would
> prefer for those people who talk to a device without ever bothering to know
> what the ECRN state is.  I have included this in the FCP-2 technical fix
> correction document, T10/97-266r2
>
>   7)  Commands with a CRN of zero shall not participate in the ordering and
>   verification procedures specified in 5.
>
>   Any command, including such initialization commands as INQUIRY, TEST UNIT
>   READY, and MODE SENSE/SELECT may always use a CRN of zero if the state of the
>   ECRN bit is not known or if execution ordering is not required for that
>   command.

I have no real objections to the above other than I am not fond of a transportlevel
concept finding its way into a SCSI mode page. This should be a FC/FCP port
characteristic only (i.e. target based).
It is unfortunate that it is deemed neccessary to be lun based today . Hopefully
disk drive vendors will see
the benefits of CRN (especially in a class 3 environment) in the future.



>
>
> I also reviewed the FCP_CONF stuff in Annex C and have the following
> thoughts.
>
> For item 5 of the guidelines, there is a statement that the use of FCP_CONF
> is required for tagged tasks.  There are many cases where tagged tasks may
> be useful without having any FCP_CONF requirements in both ordered
> and unordered tagged queueing.  A possible example is a journaling tape
> with self-identifying records of some reasonable length.  Placing such
> a restriction on the profile does not seem necessary or desirable to me.

Why is FCP_CONF a restriction? Is it a performance thing?

>
>
> I am still concerned about the absence of a model for the proper use of
> FCP_CONF.  It really is the target second-guessing when FCP_CONF will be
> useful to the recovery algorithms implemented by the initiator.  The primary
> purpose appears to be  to allow the device to discard buffers and sense
> information related to a recently completed command.  If the initiator is
> using NACA and the target is providing such commands as RECOVER BUFFERED
> DATA, then FCP_CONF will not help the recovery process.  If the initiator
> is using low-level ELS's for recovery, the FCP_CONF may help the recovery
> process by providing an additional period that the ELS's have meaning.
>
> I guess the best of all worlds would be that FCP_CONF was always used and
> the RECOVER BUFFERED DATA command and other vendor specific recovery
> algorithms could be obsoleted, but that will not
> come to pass soon, since most present host adapters do not support it
> and most drivers do use command level recovery sequences regardless of the
> type of host adapter attached (SCSI, FC-PLDA, FC-TAPE).
>
> This may be a case where a MODE SELECT parameter would actually be useful,
> telling the target what the initiator expects (no FCP_CONF, FCP_CONF on
> tagged reads only, FCP_CONF on tagged writes only, FCP_CONF on all
> tagged commands, FCP_CONF on all commands that are providing sense information
> associated with tape state, FCP_CONF on all commands providing any
> CHECK CONDITION, or any combination of these).



*
* 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 mailing list