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

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "David A. Peterson" <dap at nsco.network.com>
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: <dap at nsco.network.com>
Received: from nsco.network.com by anubis.network.com (4.1/SMI-4.1)
	id AA12020; Mon, 27 Jul 98 10:18:51 CDT
Received: from anubis.network.com by nsco.network.com (4.1/1.34)
	id AA25961; Mon, 27 Jul 98 10:18:49 CDT
Received: from network.com ([]) by anubis.network.com (4.1/SMI-4.1)
	id AA12012; Mon, 27 Jul 98 10:18:40 CDT
Message-Id: <35BCB640.CEDCA1E1 at network.com>
Date: Mon, 27 Jul 1998 10:17:53 -0700
From: "David A. Peterson" <dap at nsco.network.com>
Organization: StorageTek Network Systems Group
X-Mailer: Mozilla 4.05 [en] (Win95; I)
Mime-Version: 1.0
To: Bob Snively <Bob.Snively at ebay.sun.com>
Cc: dap at nsco.network.com, ntw20 at netcom.com, dale_lafollette at stortek.com,
        robbyb at us.ibm.com, Douglas.Hagerman at digital.com,
        charles.binford at symbios.com, bob.snively at sun.com
Subject: Re: FCP_CONF/CRN
References: <199807261935.MAA27592 at hsnwk02h.EBay.Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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 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.
> 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.

We seem to have some different ideas about error recovery.I see two levels:
1) ULP error recovery (i.e. SCSI command timeout, SCSI check condition, ...)
2) Transport level error recovery (i.e. FCP IUs, ...)
I view FCP_CONF as a tool to allow me to achieve a more robust command queueing
implementation. I fail to see how FCP_CONF is tied to error recovery. It does
the target that the sense data was received then it is up to the ULP to perform any
error recovery.
I agree if the initiator is using NACA/RECOVER BUFFERED DATA, FCP_CONF is not
That is ULP error recovery. Also I believe most (if not all) FCP engines today
implement autosense.
If the initiator is using low-level ELS's (i.e. REC/SRR) FCP_CONF should not be in
the picture
at all.

> 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