Your Message Sent on Mon, 21 Sep 1998 12:26:42 -0400
Douglas.Hagerman at digital.com
Mon Sep 28 09:54:02 PDT 1998
* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Douglas Hagerman <Douglas.Hagerman at digital.com>
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
> -----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>
> 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
> recovered by performing a READ BUFFERED DATA command, then
> 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,
> > 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
> > 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
> > 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
> > 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
More information about the T10