>Does the planner consider the bandwidth that the tape server has to
>each client? ...
In effect, yes (surprised you, didn't I? :-). It takes the average rate
of the last three full or incrementals runs and computes the estimated
time based on the estimated size.
You can see those rates with "amadmin <config> info <host> <disk>"
>If the estimation says "50 MB" and the link is 14 kbps,
>then it should be started first. :-)
FYI, it appears planner can't comprehend any client being that slow :-)
and forces the average to be at least 30 KBytes/s (DEFAULT_DUMPRATE).
Next we need to examine the driver algorithm in more detail. Some of
the base information is in the usenix paper on the ftp.amanda.org site.
There are two categories of dumpers, "little" and "big". The first three
(LITTLE_DUMPERS in driver.c) dumpers from "inparallel" are assigned
to "little" duty, everyone else is "big". Little dumpers pick entries
from the head (shortest estimated time) of the queue. Big dumpers take
entries from the end (longest estimated time) of the queue. You can see
inparallel and how many big dumpers there are in the "driver: start time"
line in amdump.<NN>.
If inparallel is set to three (or less), you don't have any "big"
dumpers and all the processing will happen from the front of the list.
If inparallel is set to four, three dumpers will be picking off the
little entries at the head of the list and one dumper will start at
the end of the list and work its way backward. If inparallel is five,
two dumpers will work from the end, and so on.
Next (regardless of big or little) come a series of constraints that may
cause a dumper to skip an entry and move on to the next (and possibly
give up/go idle if nothing can be run):
* The start time for the host or disk may not yet have been reached.
(IDLE_START_WAIT)
* The "interface" associated with the disk may be exhausted if this
dump is started. (IDLE_NO_BANDWIDTH)
* There may not be enough holding disk space. (IDLE_NO_DISKSPACE)
* The disk may be marked to go direct to tape. (IDLE_NO_HOLD)
* The client may already have maxdumps dumps running or there may
already be a dump running on that spindle (as defined in disklist).
(IDLE_CLIENT_CONSTRAINED)
All of this is documented in excruciating detail in amdump.<NN>. Look for
the "driver: state" lines that appear each time it runs through the list
and see the driver-idle: string.
So, you need to look at the list from planner and see where your problem
clients show up based on the estimated time. Assuming they have high
values and would be at the end of the list, look at inparallel and make
sure you have some "big" dumpers. Then look through an amdump.<NN>
file and see why driver is going idle and not running those dumps.
>Ben
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
