If, as per the previous email, scanner's first response is to say that it's not 
at the start of a tape when it is, physically, at the start of the tape, then 
you have lost data.  NetWorker writes file positions on tape regularly which it 
uses as reference points to confirm its position on tape - it doesn't simply 
rely on the tape driver's positional information as that can't be relied on in 
a shared environment anyway.  
 
Scanner will create "media indexes" if passed the right options.  However, I'm 
unsure what will happen to the original information which says that a 
particular saveset is at file 3 when file 3 no longer exists on that tape.  I'm 
unsure what you're getting at as regards the "nothing has been put on tape" 
comment, as neither resets, rewinds or scanner ever write to media.
 
Cheers,
 
Stuart.

________________________________

From: Dag Nygren [mailto:dag AT newtech DOT fi]
Sent: Tue 31-Oct-06 20:16
To: Stuart Whitby
Cc: EMC NetWorker discussion; Dag Nygren; dag AT newtech DOT fi
Subject: Re: [Networker] Verifying data written 



> Uhh, the error underlying this is that data has been overwritten, and that's 
> not recoverable. 

Not if you weren't writing during the reset . Then nothing has been put on
tape, and I doubt
that any media index is updated either during a read

> 
> SCSI resets will generally be caught by NetWorker and all savesets marked 
> suspect anyway.  There is some software out there (regularly for system 
> health monitoring, ironically) which will simply try to open tape handles to 
> check that things are working and will use things like /dev/rmt/0.  The OS 
> will rewind that as soon as it's closed.  There's no error apart from a delay 
> in accessing the tape drive during this time (a retryable EBUSY or similar 
> when it encounters the file lock).  NetWorker will generally check its 
> position on tape before writing, but I'm sure there are a couple of instances 
> where it just expects to be in the same place as before.

Actually the drive will generate an error but the driver usually ignores it as
it is
the same status that he drive will generate after a power on (Drive reset if I
remember rightly).

> 7.3 should get around this, but that means using 7.3.  I'm not sure if its 
> SCSI reserve is enabled by default or not.  It won't block a reset, but it 
> will block a rewind.  If you're on HP, set the st_no_rewind (I think) kernel 
> parameter to disable rewind-on-close devices, but this will only protect SAN 
> tape drives in the event that software issuing (effectively) those rewinds is 
> running on HP.

Yep.

Dag




To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu 
if you have any problems
wit this list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER