On Tue, Aug 30, 2005 at 06:01:07PM -0500, Frank Smith wrote:
> In order to tell if Amanda is deficient in some way, we need some more 
> information.
> According to the original post, this was an amflush run, so this DLE must be 
> sitting
> on a holdindisk.  Since normally Amanda refuses to backup a DLE that won't 
> fit on
> a tape and give a warning, I see two possibilities:
> 1. Your tapelength is set incorrectly in your config, so Amanda thinks a dump 
> will
>    fit when it won't

Tapelength is actually less than real tape length.  We adjusted this well 
below the real length of DLT tapes some time ago to avoid amanda 
miscalculation errors.

> 2. For some reason the dump ended up larger than the estimate, perhaps due to 
> a
>    changing filesystem or using both H/W compression on already compressed 
> data.
 
We don't use compression anywhere.  Never.  None of our backup definitions
have compression enabled.

> Is your tapelength set to something less than 34.2GB?

Yes, it's set to 30gb.  Much less than the real capacity.

> How big is the dump in the holdingdisk (not how big the chunks are, if there 
> are
> more than one, but the total of all the chunks of that DLE)?
 
53 1gb chunks.

> With that information we could find where the problem lies and maybe find a 
> solution.
 
Some part of the code mistakenly decided to store 53gb to the holding disk,
and then tried to flush it to tape, regardless of the fairly basic math
involved.

This works fine without holding disks, or when the holding disk is too
small for the backup.  The logic flaw must be somewhere in the 
"tape not available, store to holding disk for later" logic and/or "flush
this to tape" not checking the sizes involved.

I am still strongly of the opinion that amanda's handling of DLEs is still
its strongest failing point.  We're hacking vainly at something which needs
to be redesigned to work properly.

-- 
Joe Rhett
senior geek
meer.net