FCP_CONF/CRN

Rob Basham robbyb at us.ibm.com
Mon Jul 27 09:00:46 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Rob Basham <robbyb at us.ibm.com>
*
=0ATwo points on this topic from a different point of view:

1.  Unlike in Parallel SCSI, I believe that Dual Ported tape drives in =
Fibre
Channel will be common.  I also believe that Auto-Sense will be common.=


FCP_CONF is useful in cases of complete failure on one link where some =
attempt
is going to be made at the ULP to use an alternate port to the device. =
 It
allows the LUN to know that sense data was not successfully sent up on =
one port
and to send the error data again via the other port.  In the case of co=
mplete
port failure, neither ACA nor the low-level ELS's will help with gettin=
g sense
data properly reported.

The most difficult time is not when writing, which is when Recover Buff=
ered
Data is useful and could help.  The most dangerous time for alternate p=
ort
error recovery is when reading and a BLOCK SEQUENCE or POSITIONING type=
 error
is being reported.  In that case, the Recover Buffered Data scheme is o=
f no
help in alternate port error recovery.  It is while reading/spacing/loc=
ating
that I really need FCP_CONF.  FCP_CONF is helpful in some cases when wr=
iting,
but Bob is correct in that generally Recover Buffered Data would be ade=
quate.

Without FCP_CONF, in the case of alternate port error recovery we would=
 need to
devise some vendor unique way to close all the data integrity holes ass=
ociated
with SEQUENCE type errors, END OF DATA TRAVERSED, etc.  We will strongl=
y
discourage those who don't support FCP_CONF from doing alternate port e=
rror
recovery.

3..  The specification doesn't provide all the proper uses in a tape dr=
ive for
all functions.  For example, nowhere is it described why we have a Read=
 command
for tape drives.  Tools are provided and folks decide what clever way t=
hey want
to leverage those tools.  I don't believe I need to give all the uses I=
 have as
a tape device for FCP_CONF.  Suffice it to say, I believe it has value =
in other
situations like robust queueing, internal state changes, etc. and we in=
tend to
use FCP_CONF even when low-level error recovery is active and Recover B=
uffered
Data is supported.  The only case where FCP_CONF is not needed is when =
class 2
is supported, since the ACK can be leveraged for the same purposes.

Rob Basham


---------------------- Forwarded by Rob Basham/Tucson/IBM on 07/27/98 0=
8:25 AM
---------------------------


dap at nsco.network.com on 07/27/98 08:23:01 AM


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 woul=
d
> prefer for those people who talk to a device without ever bothering t=
o 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 orderi=
ng and
>   verification procedures specified in 5.
>
>   Any command, including such initialization commands as INQUIRY, TES=
T UNIT
>   READY, and MODE SENSE/SELECT may always use a CRN of zero if the st=
ate 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 FC=
P_CONF
> is required for tagged tasks.  There are many cases where tagged task=
s may
> be useful without having any FCP_CONF requirements in both ordered
> and unordered tagged queueing.  A possible example is a journaling ta=
pe
> with self-identifying records of some reasonable length.  Placing suc=
h
> 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 sen=
se
> information related to a recently completed command.  If the initiato=
r is
> using NACA and the target is providing such commands as RECOVER BUFFE=
RED
> DATA, then FCP_CONF will not help the recovery process.  If the initi=
ator
> is using low-level ELS's for recovery, the FCP_CONF may help the reco=
very
> process by providing an additional period that the ELS's have meaning=
*
* 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