Your Message Sent on Mon, 21 Sep 1998 12:26:42 -0400

[Bob Snively]

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Bob Snively <Bob.Snively at Ebay.Sun.COM>
*

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 known by the
host from the progress known by the drive.  As each write command is offered
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 error
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 tape
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, which
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 broader
> 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 parallel
> 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 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 command
> in progress
>  - Issue a Rewind command
>  - Issue a Rewind command to get back to the proper logical block number
>  - 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, there 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 recommend 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 progress.  In
> that case, no ULP recovery is attempted.  The Short error recovery method 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 recovery 
method
> that has worked in the past that will no longer work on FC-TAPE.  I have 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 myself 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 existing 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 applications
> 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