On Mon, Oct 25, 2004 at 02:44:30PM -0700, Joe Rhett wrote:
> On Mon, Oct 25, 2004 at 03:29:52PM -0500, Frank Smith wrote:
> > > USAGE BY TAPE:
> > >   Label       Time      Size      %    Nb
> > >   svk11       0:00       0.0    0.0     0
> > >   svk12       0:00       0.0    0.0     0
> > >   svk13       0:00       0.0    0.0     0
> > > 
> > > 
> > > NOTES:
> > >   planner: smaug.svk.isite.net /amandadump 20041025 0 [dump larger than 
> > > tape, 76255197 KB, full dump delayed]
> > >   taper: tape svk11 kb 34357664 fm 1 writing file: short write
> > >   taper: retrying host-xxx1.svk.isite.net:/cygdrive/c.0 on new tape: 
> > > [writing file: short write]
> > >   taper: tape svk12 kb 34352000 fm 1 writing file: short write
> > >   taper: retrying host-xxx1.svk.isite.net:/cygdrive/c.0 on new tape: 
> > > [writing file: short write]
> > >   taper: tape svk13 kb 34414784 fm 1 writing file: short write
> > >   driver: going into degraded mode because of tape error.
> 
> > I believe DLT7000s are 35GB (native) drives.  I don't know what length you
> > use in your tapetype, but evidently it's greater than 34.3GB.  Amanda is
> > trying to write an image whose size is less than or equal to your tapelength
> > (or it wouldn't have tried to write it at all) but keeps hitting EOT at
> > around 34.3GB, trying again on the next tape with the same result, etc.,
> > until all 'runtapes' tapes are used, and then gives up.
>       ..              ..
> >   First, you should probably adjust your tapelength to be slightly shorter
> > than where it hits EOT (check all the sizes in the taper lines of your
> > reports to see how much can actually be written).  
>  
> What doesn't make sense is that we usually exceed a single tape size most
> nights. It writes to one tape, then moves on to the next.  Why is this
> suddenly breaking?
> 
> > Since you have a dump larger than that, that particular DLE's backup will 
> > fail but at least the rest of your DLEs would get backed up.
> 
> And why does it assume that because it hit EOT that all the backups to the
> tape are invalid?  This makes no sense.  Only the last filesystem written
> would be invalid.

What indication do you have that it has assumed the earlier
dump files on a tape are invalid?

The results I saw in a previous issue had no dumpfiles on
the tape when the EOT was hit.  I.e. the first DLE it tried
to put onto that tape was too big for the tape.  There were
no DLE's "invalidated" that I could see.

-- 
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)