On Wed, Mar 21, 2007 at 04:27:56PM +0100, Jurgen Pletinckx wrote:
> 
> Except for the following types of failures, that is: 
> deepskyblue:/dev/xlv/xlv1                0 [dumps too big, but cannot
> incremental dump skip-incr disk]
> deepskyblue:/dev/xlv/xlv2                0 [dump larger than tape, but
> cannot incremental dump skip-incr disk]
> 
> Now, the current state of these disks is
> Filesystem             Type  kbytes     use     avail  %use Mounted on
> /dev/xlv/xlv2           xfs 71124192 57681676 13442516  82  /xlv2
> /dev/xlv/xlv1           xfs 71124160 57826144 13298016  82  /xlv1
> 
> but they were larger at the time I started amdump. (Yes, I'm doing
> a bit of spring-cleaning on the disks, while waiting for amdump to
> continue). However, they were well under 65G. I would therefore expect
> them to fit on the 70G tapes I'm using. 
> 

Guessing here.  You are using DLT tape with a 35GB "native" capacity
and believe the marketing hype that they are "70GB tapes".

Further guessing.  The previous amanda admin is using software compression
(gzip) rather than letting the hardware compress things on the fly.  This
is very typical and normal.  If so, amanda wants to know the native
capacity of the tape and that is what is specified in the "tapetype",
setting.  This is probably between 33&35GB, measured with the amtapetype
program.  If amanda has a history of these DLE it knows their compressibility.
It may be more or less than the frequently claimed 50%.

OTOH, if hardware compression is being used, most amanda admins find
the 50% compression claim of the drive manufacturer to be optimistic.
Thue your admin may have listed the tapetype capacity of the drive
as something lower than 70GB.

> Is this a problem that will disappear after a few more amdump runs?
> I.e., the planner just gets the other partitions out of the way first.
> 
> Or should I expect to have to alter the disklist, in order to split
> the contents of these large disks over different dumps? 

Probably the best thing to do at the moment is continue cleaning out
the file system debris and then retry amdump.  Later you can consider
splitting the single DLE into multiple DLEs.

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