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
