On Thu, 22 Sep 2011 19:49:45 -0400
gene heskett <[email protected]> wrote:

> Thanks for confirming what I said.  Recent work seems to have
> destroyed the planners balancing.  IMO, when it finds it has lots of
> room, it 'promotes' too aggressively, but it may be repeating level
> 0's on the smaller dle's, leaving some medium sized ones to expire
> and need a level 0 when the big stuff comes around for a level 0, and
> this seems to disagree with a 5 day cycle.

I'm not sure this makes your argument. What I didn't tell you is I have
DLEs in the hundreds of megabytes and others in the 10GB+ range. With
that, what I often see is the 10GB+ run as level 0 and everything else
run as level 1 or higher. That explains the 9/22 run in the listing in
my last email. That's the only way to get everything else backed up at
all on that run. So I expect a wide variety in the amount of data that
gets backed up on different runs.

Your point on only smaller DLEs being promoted is well taken; I've
noticed the same thing. Rarely, if ever, do my medium size DLEs get
promoted. I don't recall ever seeing the monsters ever promoted.

As long as we're thinking in terms of tapes I'm not sure I'd call the
system broken. It will back everything new up each run. If that leaves
a tape under-used, I have no problem. Occasionally it needs two tapes.
That's fine also. However, if we ever change the basic metaphor to disk
space, that could change.

> 
> > Consider enabling tape splitting. That might use your disk space
> > more efficiently than increasing the "size" of the tape.  
> 
> As in runtapes >1?  I considered that, and may yet.

Also look at:

    part-cache-type disk
    part-cache-dir "/crc/amanda10/part-cache"
    part-size 900 mb
    part-cache-max-size 900 mb

Which are per tape type, and "allow-split yes", which is per dumptype.

-- 

Charles Curley                  /"\    ASCII Ribbon Campaign
Looking for fine software       \ /    Respect for open standards
and/or writing?                  X     No HTML/RTF in email
http://www.charlescurley.com    / \    No M$ Word docs in email

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB

Reply via email to