It didn't complain (and if I'm incorrect in my assumption crowd..please
correct me) planner never takes into account the tape length so that is
why there wasn't any complaints
When taper started writing the dumps to tape and it was determined that
the filesystem exceeded the expected tape size (regardless of hardware
compression) the dumps would fail since the dumps aren't capable of
spanning tapes
You should use the compression device (/dev/rmt/0cn..depending unix
flavor) and adjust your length to be what you expect your compression to be.
Make sense??????
If I recollect (had same problem myself) the tapetype doesn't prefer the
compression it gives you the raw length of the tape...so if you had a
tapetype length of 33000 mb (+ or -) then you could set your length to
65000 mb (if using hardware compression.
As a side note make sure that you aren't using software and hardware at
the same time (speaking from experience as an amanda "freshmen" myself)
Don
Eric Trager wrote:
>On Tue, 26 Feb 2002, Don Potter wrote:
>
>>What is the length of the tapetype....using hardware compression you
>>will need to adjust the length to what you expect your actually
>>compression ratio to be..if you expect each tape to be about 70gb then
>>your length would be 70000 mbytes.
>>
>
>Ah... so perhaps this is causing the issue?
>
>define tapetype DLTtapeIV {
> comment "DLTtape IV - 40 GB"
> length 33706 mbytes
> filemark 43 kbytes
> speed 1820 kps
>}
>
>That was what the tapetype run gave us. So I guess you're saying that
>using the cbn device rather than the bn or n device is creating a
>conflict?
>
>I'm just wondering why amanda would abandon partitions... it did seem to
>properly determine that it had ~70 Gb to work with...
>
>- Eric
>
>
