No subject

[Rob Basham]

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Rob Basham <robbyb at us.ibm.com>
*
=0ABob,
I believe I've finally gotten a handle on what is bothering me about FC=
P_CONF.
I know we've talked about some of this before, but this is from a broad=
er
perspective.

Error recovery can be done at different levels.  The current FC-TAPE mo=
del does
not specify how error recovery could done at the ULP layer.  SCSI paral=
lel
error recovery for tapes at the ULP layer was not specified either.  Ev=
en
though it is not specified some people do it for various reasons.

I see two major variants of tape level error recovery:
- Quick error recovery:
 Example of who does this: AS/400 tape attach
 - Keep track of current logical block number
 - When there is a problem detected, send out an abort for any command
in progress
 - Issue a Read Position command to determine the current position
 - Issue a Locate to get back to the proper logical block number if
needed
 - Continue processing

- Long error recovery
 Example of who does this: FICON tape attach (I couldn't find any
examples in the SCSI Parallel world)
 - Keep track of the current logical block number
 - When there is a problem detected, send out an "abort" for any comman=
d
in progress
 - Issue a Rewind command
 - Issue a Rewind command to get back to the proper logical block numbe=
r
 - Continue processing

The Long error recovery method is safe for most types of processing.  T=
he
exception would be a job that is reading beyond End Of Data.  (Yes, the=
re are
applications written specifically to read beyond End Of Data to recover=

mislabeled tapes).  I'm not sure how they are going to close that hole,=
 but
they are working on it.  This would be the ULP recovery I would recomme=
nd for
FC-TAPE as it stands today.

The Quick error recovery method works on parallel SCSI for most cases, =
the
exception being those cases where a Request Sense command is in progres=
s.  In
that case, no ULP recovery is attempted.  The Short error recovery meth=
od does
not work with FC-TAPE unless FCP_CONF is requested for critical sense d=
ata.

So here is my concern:  there are applications that  have a ULP recover=
y method
that has worked in the past that will no longer work on FC-TAPE.  I hav=
e been
advertising FC-TAPE as a "drop-in" as far as the ULP layer goes.  So, w=
hile I
have a colloquial concern about dual port recovery that I can talk myse=
lf out
of worrying about, I am having a problem with the bigger issue of ULP t=
ape
error recovery for applications in general.

I think the FC-TAPE profile should be written in such a way that existi=
ng ULP
tape error recoveries don't have to change.  I agree it would be much b=
etter if
the ULP recoveries were all defined and specified.  The fact is, they e=
xist.
Either I use FCP_CONF when reporting errors, or I locate those applicat=
ions
doing this type of error recovery and demand they be ripped up before t=
hey are
ported to Fibre Channel.

Regards,
Rob Basham

T/L 321-4923  Phone 520-799-4923=
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com