--On Monday, October 25, 2004 14:44:30 -0700 Joe Rhett <jrhett AT meer DOT net>
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?
It just happens to be the oversize dump that it is attempting to write first
and failing. the 'fm' part of the taper output tells you the filemark number
of the last image it was working on, in this case it was 'fm 1' so it was
writing the first image. Perhaps your dumporder is set to try the largest
first, which normally gets the best use out of your tapes but since Amanda
thought that large dump would fit, it tried to write it. I've determined
through trial and error that I hit EOT on my 100GB tapes somewhere between
98.3 and 99 GB, so I set my tapelength to 98GB to avoid the occaisional
wasting of big chumks of tape.
>
>> 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.
That's true, but in your case nothing else was written to the tape since
the large dump was the first file.
>
>> Also, Amanda is warning you that you are no longer able to get a level 0
>> of smaug.svk.isite.net /amandadump since it is 76GB and won't fit on a
>> 35GB tape. Maybe that DLE needs to be split, or you need a bigger tape.
>
> That was a mistake on someone's part; that filesystem is a dedicated to
> amanda as a holding disk. I've removed it.
That should keep the problem from recurring soon, although you might still
want to adjust your tapelength some to avoid unneccessary rewrites from
unexpectedly hitting EOT.
Frank
>
> --
> Joe Rhett
> Senior Geek
> Meer.net
--
Frank Smith fsmith AT hoovers DOT com
Sr. Systems Administrator Voice: 512-374-4673
Hoover's Online Fax: 512-374-4501
|
