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

[Douglas Hagerman]

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Douglas Hagerman <Douglas.Hagerman at digital.com>
*
Hi Bob.

Just to clarify one small point, below, where you say "if there is a
failure", are you talking about a failure inside the tape drive, for
example a media write error? Or are you talking about an error on the
Fibre Channel interconnect.

I thought the goal here was to recover from errors on the interconnect,
which would be detected immediately and thus not generate a deferred
error.

Doug.

> -----Original Message-----
> From: Bob Snively [mailto:Bob.Snively at Ebay.Sun.COM]
> Sent: Monday, September 28, 1998 12:38 PM
> To: Bob.Snively at Ebay.Sun.COM; robbyb at us.ibm.com
> Cc: T10 at Symbios.COM; dap at nsco.network.com
> Subject: Re: Your Message Sent on Mon, 21 Sep 1998 12:26:42 -0400
> 
> 
> * 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
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com