Clearing effects of logouts on different protocols

Dave Peterson dap at cisco.com
Tue Mar 12 22:34:50 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Dave Peterson" <dap at cisco.com>
*
The tools are in place for tape applications to perform recovery for
reasonable scenarios.
Tape applications should never "assume" the tape position, this is a
potentially fatal mistake.
Read Position/Locate should be used to regain synchronization.
If they are not available a rewind and restart (for example) may be
performed.
Or lastly abort the job, and maintain data integrity.
The Networker case you describe below appears to have a data integrity
problem unless some
other action to maintain data integrity is performed prior to marking the
tape full.

Dave

> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Matthew
> Jacob
> Sent: Friday, March 08, 2002 4:05 PM
> To: Dave Peterson
> Cc: JoeBre at exabyte.com; rsnively at Brocade.COM; t10 at t10.org
> Subject: RE: Clearing effects of logouts on different protocols
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Matthew Jacob <mjacob at feral.com>
> *
>
>
> On Fri, 8 Mar 2002, Dave Peterson wrote:
>
> > RE: Clearing effects of logouts on different protocolsKeep in
> mind that it
> > is the OS tape driver/application that knows what going on. In practice,
> > the OS tape driver/application will ensure the logical unit is in the
> > proper state (from the drivers viewpoint) before reading or
> writing to the
> > device. If there is anything that would cause an undetected change thus
> > opening a data integrity hole, it needs to be fixed or at least
> > understood.
> >
> > What we need to do is to make sure the OS tape driver/application can
> > continue to operate (within reason) across events e.g., reset
> conditions.
> > If maintaining knowledge of the current partition is required for
> > continued operation we should make every attempt to do so.
>
> Yes, but the tape driver/application usually will make some pretty drastic
> recovery choices after resets. After all, a tape device with
> removable media
> is just about the most stateful device I can think of- after a reset (w/o
> qualifying what 'reset' means here), you have *no* idea where you
> are on the
> tape, or whether the tape is even the same tape any more.
>
> You can recover from this, but usually it's a (literally) expensive
> operation. If you're running something like NetWorker and were writing
> to the tape, no matter where you were, you mark the tape as
> 'full' and load
> another (via operator or from the changer). That's an expensive
> recovery from
> 'reset' in my book.
>
> *If* the tape driver is aware that only something like operating
> parameters
> were changed (and then can be restored), it *might* be safe to
> say that you
> could assume that the tape logical position is where you expected
> it to be and
> that the tape hasn't been changed. But that's a very big if.
>
>
> -matt
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list