On Fri, Jul 08, 2005 at 02:37:30PM -0500, Frank Smith wrote:
> --On Friday, July 08, 2005 10:58:25 -0400 Gene Heskett <gene.heskett AT
> verizon DOT net> wrote:
>
> > On Friday 08 July 2005 09:44, Jon LaBadie wrote:
> >> On Fri, Jul 08, 2005 at 10:18:53AM +0200, MATILDA MATILDA wrote:
> >>> Hi all,
> >>>
> >>> After backup I run amverifyrun to check the backup. Now I have the
> >>> following situation and I don't know if this behaviour is intended
> >>> or I'm doing something wrong.
> >>
> >> brief synopsis:
> >> on a multi-tape run
> >> amverify notes an incomplete dump file at the end of a tape
> >> marks that as an error
> >> finds the complete dump file on the next tape
> >> does not remove the earlier error
> >> thus generates a report showing errors
> >>
> >>> My question: Is there a way to check that backup so that I get an
> >>> error when there is really an error in the backup set? In this
> >>> context error means to me that I probably can't restore alle
> >>> tar-files I backed up before.
> >>
> >> Seems to me that your desired behavior would be reasonable.
> >>
> >> It could be a real bear to test, having to read through entire tapes
> >> before getting to the test point.
> >>
> >> I hope someone with a vtape test setup can duplicate the problem and
> >> use that as a testbed instead.
> >
> > I'm running vtapes here. This was indeed true the last time I tried
> > runtapes=2, Jon. There were also some other amverifyish housekeeping
> > problems whose details I don't recall now as that was several (6+)
> > months back up the log and none of the examples now exist.
> >
> > To me, the obvious cure would be to remove the partial file, a piece
> > of cake in a vtape setup, but in a tape environment, that would
> > require keeping track of the fm's so that a backspace could be done
> > and the partial files header overwritten with an EOT marker & 32k
> > of /dev/zero before going on to the next tape in the magazine &
> > restarting the failed file. Thats a lot of wear and tear on both the
> > tape and the drive IMO, so the real cure should be done in amverify
> > itself.
>
> This seems dangerous to me. Besides the fact that some drives don't
> backspace well (speed-wise), even on a vtape an error in your
> positioning would cause loss of data.
> It seems easier and safer to to just have amverify buffer the
> error and if it is successful in reading the DLE from the next
> tape don't output the error.
>
>
Agreed, safety and time make it undesireable to my thinking.
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
