FCP_CONF relative to ULP Recovery
robbyb at us.ibm.com
Mon Sep 28 11:02:20 PDT 1998
* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Rob Basham <robbyb at us.ibm.com>
You did not address ULP recoveries concerned with Reads. For the most =
I am comfortable with ULP recoveries on Write commands with this profil=
block sequence type errors are very rare on Write type commads.
T/L 321-4923 Phone 520-799-4923
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=
to the tape drive, it is executed, data is transferred to a buffer, and=
command is completed. After enough data is buffered up, operations to =
medium begin. If there is a failure, it is necessarily a deferred erro=
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=
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_=
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=
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-=
> I believe I've finally gotten a handle on what is bothering me about =
> I know we've talked about some of this before, but this is from a bro=
> Error recovery can be done at different levels. The current FC-TAPE =
> not specify how error recovery could done at the ULP layer. SCSI par=
> error recovery for tapes at the ULP layer was not specified either. =
> 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=
> 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
> - 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=
> in progress
> - Issue a Rewind command
> - Issue a Rewind command to get back to the proper logical block num=
> - Continue processing
> The Long error recovery method is safe for most types of processing. =
> exception would be a job that is reading beyond End Of Data. (Yes, t=
> applications written specifically to read beyond End Of Data to recov=
> mislabeled tapes). I'm not sure how they are going to close that hol=
> they are working on it. This would be the ULP recovery I would recom=
> FC-TAPE as it stands today.
> The Quick error recovery method works on parallel SCSI for most cases=
> exception being those cases where a Request Sense command is in progr=
> that case, no ULP recovery is attempted. The Short error recovery me=
> not work with FC-TAPE unless FCP_CONF is requested for critical sense=
> So here is my concern: there are applications that have a ULP recov=
> that has worked in the past that will no longer work on FC-TAPE. I h=
> advertising FC-TAPE as a "drop-in" as far as the ULP layer goes. So,=
> have a colloquial concern about dual port recovery that I can talk my=
> of worrying about, I am having a problem with the bigger issue of ULP=
> error recovery for applications in general.
> I think the FC-TAPE profile should be written in such a way that exis=
> tape error recoveries don't have to change. I agree it would be much=
> the ULP recoveries were all defined and specified. The fact is, they=
> Either I use FCP_CONF when reporting errors, or I locate those applic=
> doing this type of error recovery and demand they be ripped up before=
> ported to Fibre Channel.
> 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
More information about the T10