On Fri, Jul 08, 2005 at 02:37:30PM -0500, Frank Smith wrote: > --On Friday, July 08, 2005 10:58:25 -0400 Gene Heskett <[EMAIL PROTECTED]> > 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 [EMAIL PROTECTED] JG Computing 4455 Province Line Road (609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
