[Fwd: FCP_CONF/CRN]
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.
--------------DB470BD0A174A7651254074E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--------------DB470BD0A174A7651254074E
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 ([129.191.10.230]) 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
inform
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
useful.
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).
--------------DB470BD0A174A7651254074E--
*
* 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