Amanda-Users

Re: taperalgo LARGEST does not seem to work

2003-04-30 13:31:59
Subject: Re: taperalgo LARGEST does not seem to work
From: Orion Poplawski <orion AT cora.nwra DOT com>
To: Paul Bijnens <paul.bijnens AT xplanation DOT com>
Date: Wed, 30 Apr 2003 11:27:48 -0600
Paul Bijnens wrote:

Orion Poplawski wrote:


Taper starts as soon as it has an image available.
When more than one are available, taperalgo chooses one.


Anyway to delay taper until the dumps are complete? Not sure I really want to do this, but might be nice to try it out.


   What I want is to write the tape in decreasing order of dump size.


You can improve on this by specifying a "dumporder" for your dumpers.
Something like:
   dumporder "SSSSSSSS"
(as many as you have dumpers)

Now you get large dumps first.  It's still not yet in decreasing order,
because you start many dumpers at once, and the first one to finish
of the bunch is put on tape first.  That's usually the smallest of the
large ones (if you understand what I mean).  You could run less dumpers
if that's what you want.


Hmm, so it seems that parrallel dumping is incompatible with my goal writing to tape in decreasing size. Although if the taper were set to wait until all dumps were completed, I could set dumporder to "TTTTT" and presumably achieve the fastest overall dump time while still writing to tape in the desired order.


The problem I'm running into is that I tend to have some very large level 0's (almost the size of the tape) and fairly small incrementals. If the tape fills up during the run, inevitably it is the large level 0 that fails, leaving the tape almost unused. See amdump output below.


One way to improve on this too is to split up the large dump in smaller
if you are using GNUTAR.
I do both: specify dumporder, and split up large dump into more
manageable pieces.  My first 2 tapes (with runtapes=3) are filled
more than 95% (AIT-3, 35 GByte native).


Good suggestion. Unfortunately I'm already splitting up 120GB drives into chunks that will fit on my 40GB tapes and I'd like to avoid having a large disklist that requires lots of maintenance.

Thanks for the response.

- Orion

--
Orion Poplawski
System Administrator                   303-415-9701 x222
Colorado Research Associates/NWRA      FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301   www.co-ra.com