FCP_CONF relative to ULP Recovery

[Rob Basham]

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Rob Basham <robbyb at us.ibm.com>
*
=0ABob,

You did not address ULP recoveries concerned with Reads.  For the most =
part,
I am comfortable with ULP recoveries on Write commands with this profil=
e;
block sequence type errors are very rare on Write type commads.

Regards,
Rob Basham

T/L 321-4923  Phone 520-799-4923

Rob,

I am not sure I follow your arguement that FCP_CONF and "quick error"
recovery you describe are somehow linked.  At present, most of the SCSI=

tape drives use a write cache mechanism that isolates the progress know=
n by the
host from the progress known by the drive.  As each write command is of=
fered
to the tape drive, it is executed, data is transferred to a buffer, and=
 the
command is completed.  After enough data is buffered up, operations to =
the
medium begin.  If there is a failure, it is necessarily a deferred erro=
r
except for certain synchronizing commands.  Such failures are routinely=

recovered by performing a READ BUFFERED DATA command, then constructing=

a new command which can send out the recovered data in a subsequent
write command, perhaps even to a new tape.

As a result, until you do real command queueing (not executed by any ta=
pe
at present), there is no mechanism to tie the current logical block
number known to the media to the current operation being performed by
the host to the tape drive.  As a result, FCP_CONF is totally useless
in that environment.

The model that Dave Peterson has brought forward correctly assigns FCP_=
CONF
to some very particular functions in the tape drive.  He indicates that=

FCP_CONF should be used only for:

 tape drives that support the function attached to initiators that
  support the function.

 presenting check conditions.

 tagged command queueing, especially read commands.

What this does is provide a cleaner and different recovery mechanism, w=
hich
is the only reason we are interested in FCP_CONF in the first place.

If you would like to further discuss this, you can reach me at 510-574-=
9051.

Bob

>
> Bob,
> I believe I've finally gotten a handle on what is bothering me about =
FCP_CONF.
> I know we've talked about some of this before, but this is from a bro=
ader
> perspective.
>
> Error recovery can be done at different levels.  The current FC-TAPE =
model
does
> not specify how error recovery could done at the ULP layer.  SCSI par=
allel
> error recovery for tapes at the ULP layer was not specified either.  =
Even
> 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 comman=
d
> 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 comm=
and
> in progress
>  - Issue a Rewind command
>  - Issue a Rewind command to get back to the proper logical block num=
ber
>  - Continue processing
>
> The Long error recovery method is safe for most types of processing. =
 The
> exception would be a job that is reading beyond End Of Data.  (Yes, t=
here are
> applications written specifically to read beyond End Of Data to recov=
er
> mislabeled tapes).  I'm not sure how they are going to close that hol=
e, but
> they are working on it.  This would be the ULP recovery I would recom=
mend 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 progr=
ess.  In
> that case, no ULP recovery is attempted.  The Short error recovery me=
thod does
> not work with FC-TAPE unless FCP_CONF is requested for critical sense=
 data.
>
> So here is my concern:  there are applications that  have a ULP recov=
ery
method
> that has worked in the past that will no longer work on FC-TAPE.  I h=
ave been
> advertising FC-TAPE as a "drop-in" as far as the ULP layer goes.  So,=
 while I
> have a colloquial concern about dual port recovery that I can talk my=
self out
> of worrying about, I am having a problem with the bigger issue of ULP=
 tape
> error recovery for applications in general.
>
> I think the FC-TAPE profile should be written in such a way that exis=
ting ULP
> tape error recoveries don't have to change.  I agree it would be much=
 better
if
> the ULP recoveries were all defined and specified.  The fact is, they=
 exist.
> Either I use FCP_CONF when reporting errors, or I locate those applic=
ations
> doing this type of error recovery and demand they be ripped up before=
 they 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