I've just started backing up my 3+TB of RAID space to an Overland Library 
Pro system with 1 AIT3 drive using amanda 2.4.3.  I initially set runtapes 
to 3, but have since cranked that back to 2.  I immediately noticed that 
amanda wasn't too smart when it came to putting stuff on tape.  (Given how 
smart it is about everything else, this rather shocked me.)  Watching an 
amdump in progress, I could see it start taping something I knew wouldn't 
fit on the current tape, given how much had already gone on it.  When your 
dump images are on the order of scores of gigabytes, this can lead to a 
*lot* of wasted time re-taping stuff, not to mention wasted tape space.

Looking through the code, I see that the 2.4.3 driver has no concept of 
tape_length; planner uses tape->length*runtapes.  Looking through the 
2.4.4b1 source, this appears to be changed due to the addition of 
"taperalgo" config flag.  Can someone more familiar with the code confirm 
my suspicions?  If I use the "largestfit" taperalgo, will amanda only try 
to tape images which will *actually* fit on on a tape of tape_length?  
Also, what is a good dumporder flag (or a starting point) to select to 
optimize time and tape usage?

Thanks.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University