Re: Amanda "info on small DLEs not saved" bug -- proposed patch

2018-11-11 Thread Gene Heskett 
On Sunday 11 November 2018 15:57:13 Nathan Stratton Treadway wrote:

> On Sun, Nov 11, 2018 at 15:20:54 -0500, Gene Heskett wrote:
> > Please do not throw wheezy support under the bus just yet, there are
>
> (Jose is talking about working on an update for the Debian packaging
> of Amanda, but you build your own installations direclty from the
> upstream Amanda source release anyway, so Jose's work won't affect
> you)
>
Not the same concern as amanda at all, but there is currently quite a 
bruhaha over the diffs for libcurl3 vs libcurl4 on the *buntu lists, and 
this shouldn't be a reason to drop wheezy support.

Yes, I build my own but thats in self defense to maintain compatibility 
continuity in the face of every developer using his own pet configure 
script. Mine seems to do that compatibility thing quite well. Its been 
posted here in the last 2 weeks or so if you want to check it out. As 
gh.cf.

Most of the clients here are running the often older distro version of 
amanda_client. Looks like my lonely jessie install on the r-pi is using 
an older 3.3.6-4 version. Works well so far, ignore the faint thumping 
sound. :)

>   Nathan
> --
>-- Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic
> region Ray Ontko & Co.  -  Software consulting services  -  
> http://www.ontko.com/ GPG Key:
> http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239 Key
> fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239



Copyright 2018 by Maurice E. Heskett
-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page

Re: All level 0 on the same run?

2018-11-11 Thread Gene Heskett 
On Sunday 11 November 2018 15:36:52 Nathan Stratton Treadway wrote:

> On Sun, Nov 11, 2018 at 05:25:29 -0500, Gene Heskett wrote:
> > > > amanda@coyote:/amandatapes/Dailys/data$ /usr/local/sbin/amadmin
> > > > Daily balance
> > > >
> > > >  due-date  #fsorig MB out MB   balance
> > > > --
> > > > 11/10 Sat1   7912   3145-78.7%
> > > > 11/11 Sun1  10886  10886-26.1%
> > > > 11/12 Mon1  32963   7875-46.6%
> > > > 11/13 Tue1   7688   7688-47.8%
> > > > 11/14 Wed2  22109  22109+50.0%
> > > > 11/15 Thu4  75027  46623   +216.3%
> > > > 11/16 Fri6   8257   6109-58.6%
> > > > 11/17 Sat   29  14034   8932-39.4%
> > > > 11/18 Sun4  21281  16842+14.3%
> > > > 11/19 Mon   18  34599  17188+16.6%
> > > > --
> > > > TOTAL   67 234756 147397 14739
>
> [...]
>
> > After this mornings run, its better again:
> > amanda@coyote:/root$ /usr/local/sbin/amadmin Daily balance
> >
> >  due-date  #fsorig MB out MB   balance
> > --
> > 11/11 Sun1  10886  10886-35.8%
> > 11/12 Mon1  32963   7875-53.6%
> > 11/13 Tue1   7688   7688-54.7%
> > 11/14 Wed2  22109  22109+30.4%
> > 11/15 Thu4  75027  46623   +175.0%
> > 11/16 Fri6   8257   6109-64.0%
> > 11/17 Sat   29  14034   8932-47.3%
> > 11/18 Sun4  21281  16842 -0.7%
> > 11/19 Mon   18  34599  17188 +1.4%
> > 11/20 Tue1  49240  25295+49.2%
> > --
> > TOTAL   67 276084 169547 16954
> >   (estimated 10 runs per dumpcycle)
> >
> > And it must be calculating the balance based on the original size,
> > not the compressed size (out MB), that growing Tuesday the 20th is
> > still on one vtape, but if unchanged, Thu 15nth will still use a 2nd
> > vtape.
>
> Comparing these two runs, I see that all the rows (the first four
> columns on each line) are the same -- except that the single DLE
> listed on 11/10 of the first run came out much larger when it was
> actually dumped last night.  (7912/3145 v.s. 49240/25295).  When you
> said "that growing Tuesday the 20th", was that an indication that you
> already expected that particular DLE (which should be easy to identify
> as the only full dump listed in last night's report) to be growing
> rapidly?
>
> (Note that the "balance" column is in fact calculated based on the
> compressed/"out MB": the "average size" of 16954 listed at the bottom
> of the "balance" column is sum-of-all-"out"-sizes/runs-per-dumpcycle
> (i.e. the average of the out-sizes), and then the balance percentile
> in each row is (today's-out-MB less average-size)/average-size.  For
> example, for 11/20, you have
>   (25295-16954) / 16954 = 0.492
> ,and for 11/16 you have
>   ( 6109-16954) / 16954 = -0.640
> , etc.)
>
> So, from these two days of "balance" reports, the takeaway is that one
> particular DLE seems to have become much bigger (3145 -> 25295 MB
> compressed size), and as a result the average dump size went up by
> 2200MB, and thus all the positive-balance days had their balance
> percentages go down a bit.  So the balance did improve, but because of
> the growth of the total backup volume rather than because of
> rescheduling any particular dump(s).
>
> Also, the fact that this one DLE grew to be larger than the average
> dump size explains why no other DLEs were promoted to last night's run
> (and thus none of the other date's rows changed at all).
>
> However, the next three days all show negative balance figures, so it
> will be interesting to see if Amanda promotes any DLEs from the 11/14,
> 11/15, or 11/19's groups to try to even the batches out a bit.
> However, the first two of those dates currently have small DLE counts,
> and 11/19 includes many DLEs but totals just slightly over the
> average, so the opportunities for rebalancing may be pretty
> limited
>

it is an improvement, so I'm not going to try and move anything else for 
about a week just to see if it levels out better. PublicA is currently 
the 800 lb gorilla, so I may next attempt to adapt one of the recipes 
for a-f etc in the top of the disklist. 3, maybe even 4 of those might 
get it under control.  And its a technique I've not yet explored. 
>   Nathan
>
> --
>-- Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic
> region Ray Ontko & Co.  -  Software consulting services  -  
> http://www.ontko.com/ GPG Key:
> http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239 Key
> fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 623

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

2018-11-11 Thread Nathan Stratton Treadway 
On Sun, Nov 11, 2018 at 15:20:54 -0500, Gene Heskett wrote:
> Please do not throw wheezy support under the bus just yet, there are 

(Jose is talking about working on an update for the Debian packaging of
Amanda, but you build your own installations direclty from the upstream
Amanda source release anyway, so Jose's work won't affect you)

Nathan

Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

2018-11-11 Thread Nathan Stratton Treadway 
On Sun, Nov 11, 2018 at 18:35:01 +, Jose M Calhariz wrote:
> On Sun, Nov 11, 2018 at 01:12:04PM -0500, Nathan Stratton Treadway wrote:
> > Sounds great, thanks.  Let me know when you have some
> > packages/source-package to download and I can give it a try here. 
> > (Hopefully you'll also get a chance to investigate the libcurl3 v.s.
> > libcurl4 dependency problems I ran into on the WIP package version you
> > had last September.)
> 
> I have not.  What is you OS, I can try to compile the packages for you
> or give you instructions on how to compile.

The issue I had was that the WIP packages you build in September seem to
have been built in an environment where somehow both libcurl3 and
libcurl4-openssl-dev were installed, and those two are incompatible. 
(Well, they definitely were incompatible in Ubuntu Bionic, and looked at
the package-website listings for the Debian repository they looked like
they would conflict in Debian, too.)

I was able to rebuild from your source package on my Bionic system with
no problem (and no changes to the source other than the Debian changelog
entry, as I recall), so I think the issue is limited to the build
environment where you built those particular .deb files

(See my (private) emails to you from
  Date: Thu, 20 Sep 2018 20:38:52 -0400
and
  Date: Mon, 24 Sep 2018 23:23:54 -0400
for more details.)


Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Re: All level 0 on the same run?

2018-11-11 Thread Nathan Stratton Treadway 
On Sun, Nov 11, 2018 at 05:25:29 -0500, Gene Heskett wrote:
> > > amanda@coyote:/amandatapes/Dailys/data$ /usr/local/sbin/amadmin
> > > Daily balance
> > >
> > >  due-date  #fsorig MB out MB   balance
> > > --
> > > 11/10 Sat1   7912   3145-78.7%
> > > 11/11 Sun1  10886  10886-26.1%
> > > 11/12 Mon1  32963   7875-46.6%
> > > 11/13 Tue1   7688   7688-47.8%
> > > 11/14 Wed2  22109  22109+50.0%
> > > 11/15 Thu4  75027  46623   +216.3%
> > > 11/16 Fri6   8257   6109-58.6%
> > > 11/17 Sat   29  14034   8932-39.4%
> > > 11/18 Sun4  21281  16842+14.3%
> > > 11/19 Mon   18  34599  17188+16.6%
> > > --
> > > TOTAL   67 234756 147397 14739
> > >
[...] 
> After this mornings run, its better again:
> amanda@coyote:/root$ /usr/local/sbin/amadmin Daily balance
> 
>  due-date  #fsorig MB out MB   balance
> --
> 11/11 Sun1  10886  10886-35.8%
> 11/12 Mon1  32963   7875-53.6%
> 11/13 Tue1   7688   7688-54.7%
> 11/14 Wed2  22109  22109+30.4%
> 11/15 Thu4  75027  46623   +175.0%
> 11/16 Fri6   8257   6109-64.0%
> 11/17 Sat   29  14034   8932-47.3%
> 11/18 Sun4  21281  16842 -0.7%
> 11/19 Mon   18  34599  17188 +1.4%
> 11/20 Tue1  49240  25295+49.2%
> --
> TOTAL   67 276084 169547 16954
>   (estimated 10 runs per dumpcycle)
> 
> And it must be calculating the balance based on the original size, not 
> the compressed size (out MB), that growing Tuesday the 20th is still on 
> one vtape, but if unchanged, Thu 15nth will still use a 2nd vtape.

Comparing these two runs, I see that all the rows (the first four
columns on each line) are the same -- except that the single DLE listed
on 11/10 of the first run came out much larger when it was actually
dumped last night.  (7912/3145 v.s. 49240/25295).  When you said "that
growing Tuesday the 20th", was that an indication that you already
expected that particular DLE (which should be easy to identify as the
only full dump listed in last night's report) to be growing rapidly?

(Note that the "balance" column is in fact calculated based on the
compressed/"out MB": the "average size" of 16954 listed at the bottom of
the "balance" column is sum-of-all-"out"-sizes/runs-per-dumpcycle (i.e.
the average of the out-sizes), and then the balance percentile in each
row is (today's-out-MB less average-size)/average-size.  For example,
for 11/20, you have
  (25295-16954) / 16954 = 0.492
,and for 11/16 you have 
  ( 6109-16954) / 16954 = -0.640
, etc.)

So, from these two days of "balance" reports, the takeaway is that one
particular DLE seems to have become much bigger (3145 -> 25295 MB
compressed size), and as a result the average dump size went up by
2200MB, and thus all the positive-balance days had their balance
percentages go down a bit.  So the balance did improve, but because of
the growth of the total backup volume rather than because of
rescheduling any particular dump(s).  

Also, the fact that this one DLE grew to be larger than the average dump
size explains why no other DLEs were promoted to last night's run (and
thus none of the other date's rows changed at all).

However, the next three days all show negative balance figures, so it
will be interesting to see if Amanda promotes any DLEs from the 11/14,
11/15, or 11/19's groups to try to even the batches out a bit. 
However, the first two of those dates currently have small DLE counts,
and 11/19 includes many DLEs but totals just slightly over the average,
so the opportunities for rebalancing may be pretty limited

Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

2018-11-11 Thread Gene Heskett 
On Sunday 11 November 2018 13:35:01 Jose M Calhariz wrote:

> On Sun, Nov 11, 2018 at 01:12:04PM -0500, Nathan Stratton Treadway 
wrote:
> > On Sun, Nov 11, 2018 at 14:43:48 +, Jose M Calhariz wrote:
> > > Thank you Nathan for your work on this.  It gives me some hope for
> > > the future of amanda.
> >
> > (Well, this one was right at the edge my understanding of Amanda's
> > internals, so as far as the future of Amanda I hope you aren't
> > confusing me with an actual Amanda developer! :) )
> >
> > > I am preparing a new release of amanda 3.5.1 for Debian unstable
> > > and stretch with this fix and other fix from JLM.  I will be back
> > > with more information after some testing on my amanda servers.
> >
> > Sounds great, thanks.  Let me know when you have some
> > packages/source-package to download and I can give it a try here.
> > (Hopefully you'll also get a chance to investigate the libcurl3 v.s.
> > libcurl4 dependency problems I ran into on the WIP package version
> > you had last September.)
>
> I have not.  What is you OS, I can try to compile the packages for you
> or give you instructions on how to compile.
>
> > Nathan

Please do not throw wheezy support under the bus just yet, there are 
those of us still running it because the app it has to run, which milks 
the cash cow, LinuxCNC, runs best on an i386 install, even if the cpu 
itself is 64 bitter! The 64 bit architecture may be able to do more, but 
it simply takes too long to respond to an IRQ due its its increased data 
to swap for a context switch. A 5 microsecond increase in that latency 
can ruin parts AND BREAK TOOLS by causing motor stalls where once there 
were none.

There is progress being made on a 64 bit stretch version, but some users 
may be required to spend additional money bringing in a consultant 
because they are machinists, not computer/electronics whizzes, to up 
grade the machines controller interfacing to actually do good work with 
the new 64 bit stuff.

I am doing it, but there's more than $200 in interfacing cards just so I 
can do it with a $32 Raspi-3b running a jessie 64 bit install.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

2018-11-11 Thread Jose M Calhariz 
On Sun, Nov 11, 2018 at 01:12:04PM -0500, Nathan Stratton Treadway wrote:
> On Sun, Nov 11, 2018 at 14:43:48 +, Jose M Calhariz wrote:
> > Thank you Nathan for your work on this.  It gives me some hope for the
> > future of amanda.
> 
> (Well, this one was right at the edge my understanding of Amanda's
> internals, so as far as the future of Amanda I hope you aren't confusing
> me with an actual Amanda developer! :) )
> 
> > 
> > I am preparing a new release of amanda 3.5.1 for Debian unstable and
> > stretch with this fix and other fix from JLM.  I will be back with
> > more information after some testing on my amanda servers.
> 
> Sounds great, thanks.  Let me know when you have some
> packages/source-package to download and I can give it a try here. 
> (Hopefully you'll also get a chance to investigate the libcurl3 v.s.
> libcurl4 dependency problems I ran into on the WIP package version you
> had last September.)

I have not.  What is you OS, I can try to compile the packages for you
or give you instructions on how to compile.


> 
>   Nathan
> 
> Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
> Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
>  GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
>  Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239
> 
> 

Kind regards
Jose M Calhariz


-- 
--
O homem vale o que vale o seu ideal, esta e a sua medida
-- J. Maira Puladas


signature.asc
Description: PGP signature

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

2018-11-11 Thread Nathan Stratton Treadway 
On Sun, Nov 11, 2018 at 14:43:48 +, Jose M Calhariz wrote:
> Thank you Nathan for your work on this.  It gives me some hope for the
> future of amanda.

(Well, this one was right at the edge my understanding of Amanda's
internals, so as far as the future of Amanda I hope you aren't confusing
me with an actual Amanda developer! :) )

> 
> I am preparing a new release of amanda 3.5.1 for Debian unstable and
> stretch with this fix and other fix from JLM.  I will be back with
> more information after some testing on my amanda servers.

Sounds great, thanks.  Let me know when you have some
packages/source-package to download and I can give it a try here. 
(Hopefully you'll also get a chance to investigate the libcurl3 v.s.
libcurl4 dependency problems I ran into on the WIP package version you
had last September.)

Nathan

Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

2018-11-11 Thread Jose M Calhariz 
Thank you Nathan for your work on this.  It gives me some hope for the
future of amanda.

I am preparing a new release of amanda 3.5.1 for Debian unstable and
stretch with this fix and other fix from JLM.  I will be back with
more information after some testing on my amanda servers.

Kind regards
Jose M Calhariz

On Fri, Nov 09, 2018 at 06:00:41PM -0500, Nathan Stratton Treadway wrote:
> On Fri, Nov 02, 2018 at 13:00:38 -0400, Nathan Stratton Treadway wrote:
> > On Fri, Nov 02, 2018 at 12:35:06 -0400, Gene Heskett wrote:
> > 
> > > Fri Nov 02 03:42:06.085962877 2018: pid 13139: thd-0x9824e00: driver: not 
> > > updating because origsize or dumpsize is 0
> > > Fri Nov 02 03:42:06.086158866 2018: pid 13139: thd-0x9824e00: driver: 
> > > Building type FILE header of 32768-32768 bytes with name='coyote' 
> > > disk='/usr/games' 
> > > dumplevel=1 and blocksize=0
> > > Fri Nov 02 03:42:06.086317001 2018: pid 13139: thd-0x9824e00: driver: 
> > > Building type FILE header of 32768-32768 bytes with name='coyote' 
> > > disk='/usr/games' 
> > > dumplevel=1 and blocksize=0
> > > Fri Nov 02 03:42:06.092807051 2018: pid 13139: thd-0x9824e00: driver: 
> > > driver: send-cmd time 2461.017 to taper0: FILE-WRITE worker0-0 
> > > 00-00130 /usr/dumps/20181102030105/coyote._usr_games.1 coyote /usr/games 
> > > 1 20181102030105 "" "" "" 1 "" "" "" "" 10
> > > 
> > 
> > Ah, interesting, looks like this applies to level 1 dumps as well.  What
> > does "amadmin CONFIG info coyote /usr/games shop /usr/lib/amanda" output?
> 
> 
> 
> Okay, I believe I have tracked down this "info on small DLEs not saved"
> bug...
> 
> 
> Summary:
> 
> The short-ish summary is that in Amanda 3.4 and 3.5, any dump which ends
> but being shorter than 1024 bytes long (after compression) is treated as
> not having happened at all, as far as Amanda's recording of "info"
> statistics goes.
> 
> This is most significant for full dumps (i.e. of very small partitions),
> because it causes Amanda to think that DLE has never been dumped (or,
> that the last time it was dumped was on the final run made using Amanda
> 3.3 or older), and thus it schedules that DLE for a full dump on every
> run.
> 
> However, the bug actually also affects incremental dumps (as we
> discussed in the above-quoted message) -- so DLEs that don't change much
> on a particular day and thus end up with very tiny incrementals end up
> recording those dumps as having taken place on 1969/12/31 rather than
> the day they actually occurred.
> 
> 
> Neither of the above situations is "fatal" as far as preventing Amanda
> from actually backup up your data, but for people (such as Gene) who are
> effected, a workaround workaround is simply to make sure that the dump
> on a particular day is at least 1024 bytes.
> 
> For full dumps, you can do this just by creating a "dummy" file on the
> otherwise-very-empty partition in question, using data that's already
> compressed so that the dump file is still big enough after Amanda
> compresses it.  (In my tests, I just used the bytes off the front of the
> amanda_3.4.2.orig.tar.gz file I happened to have sitting around.)
> 
> (For incrementals the trick is to make sure there is enough changing on
> the partition that the incremental dump is over the cutoff size; the
> best way to do that will depend on what data is on that partition, etc.)
> 
> 
> 
> Internal details and history: 
> 
> The bug happens because the messages that the chunker and driver
> processes use to communicate with each other specify the size of the
> files transferred in integral units of "kb" (=1024 bytes), and thus the
> size given for very small files is "0" -- but the code in the driver
> that handles updating the info database has a specific check for
> zero-length dumps and refuses to update the database in that case. 
> (This check is found in driverio.c:update_info_dumper() .)
> 
> It appears that the bug has existed since Amanda 3.4, when the old
> chunker.c version of the chunker program was replaced with a new Perl
> version.  
> 
> Both server-src/chunker.c as found in Amanda 3.3 and server-src/dumper.c
> as it exists in 3.5 take special care to round "kb" value passed for
> files which are short-but-not-empty files up to "1" -- but that logic
> was not implemented in the Perl chunker code when it was created..
> 
> (Interestingly, if I am reading the old chunker.c code correctly, it
> used to round up not just very-small-but-not-empty files to 1 kb, but
> actually rounded the kb figure up to count any trailing partial
> kilobytes at the end of the file... while the new program seems to just
> ignore those trailing partial kilobytes.  Presumably this difference
> simply doesn't matter -- except for the when the size is rounded down to
> zero.)
> 
> 
> Proposed patch:
> 
> This is where having an actual Amanda developer would be very handy...
> but given that planner.c and old-chunker.c both have special handling
> for small-but-not-empty files, I figured that adding a s

Re: All level 0 on the same run?

2018-11-11 Thread Gene Heskett 
On Saturday 10 November 2018 13:55:30 Nathan Stratton Treadway wrote:

[...]
> > > >  due-date  #fsorig MB out MB   balance
> > > > --
> > > > 10/30 Tue5  0  0  ---
> > > > 10/31 Wed1  17355   8958-45.3%
> > > > 11/01 Thu2  10896  10887-33.5%
> > > > 11/02 Fri4  35944   9298-43.2%
> > > > 11/03 Sat4  14122  10835-33.8%
> > > > 11/04 Sun3  57736  57736   +252.7%
> > > > 11/05 Mon2  39947  30635+87.1%
> > > > 11/06 Tue8   4235   4215-74.3%
> > > > 11/07 Wed4  19503  14732-10.0%
> > > > 11/08 Thu   32  31783  16408 +0.2%
> > > > --
> > > > TOTAL   65 231521 163704 16370
[...]
> > What does your "balance" output show now?
[...]
> > Its some better:
> > amanda@coyote:/amandatapes/Dailys/data$ /usr/local/sbin/amadmin
> > Daily balance
> >
> >  due-date  #fsorig MB out MB   balance
> > --
> > 11/10 Sat1   7912   3145-78.7%
> > 11/11 Sun1  10886  10886-26.1%
> > 11/12 Mon1  32963   7875-46.6%
> > 11/13 Tue1   7688   7688-47.8%
> > 11/14 Wed2  22109  22109+50.0%
> > 11/15 Thu4  75027  46623   +216.3%
> > 11/16 Fri6   8257   6109-58.6%
> > 11/17 Sat   29  14034   8932-39.4%
> > 11/18 Sun4  21281  16842+14.3%
> > 11/19 Mon   18  34599  17188+16.6%
> > --
> > TOTAL   67 234756 147397 14739
> >
> > It will be interesting to see if it continues to get "better".
> > I should think it will be under 150% by the 15nth if so. If the
> > planner behaves itself.
>
[]
> (I am pretty sure that the small-DLE bug didn't affect the overall
> balance.  You can see from the "balance" output on 10/30 that the 5
> DLEs in question all show up as needing to be full-dumped that day --
> but the total size for that group is still zero.  So I suspect that
> there is/are some other factor(s) behind the single-day surge and
> whatever "shuffling" has been going on ...)
>
> > We shall see. Perhaps I could add a balance report to the end of
> > backup.sh so I get it emailed to me every morning? I'll take a look
> > after ingesting enough caffeine to get both eyes open
> > simultaneously.
>
> Yes, if you are trying to really understand what's going on with the
> scheduling it can certainly be useful to be able to watch the
> day-to-day changes to the balance listing.
>
>   Nathan

After this mornings run, its better again:
amanda@coyote:/root$ /usr/local/sbin/amadmin Daily balance

 due-date  #fsorig MB out MB   balance
--
11/11 Sun1  10886  10886-35.8%
11/12 Mon1  32963   7875-53.6%
11/13 Tue1   7688   7688-54.7%
11/14 Wed2  22109  22109+30.4%
11/15 Thu4  75027  46623   +175.0%
11/16 Fri6   8257   6109-64.0%
11/17 Sat   29  14034   8932-47.3%
11/18 Sun4  21281  16842 -0.7%
11/19 Mon   18  34599  17188 +1.4%
11/20 Tue1  49240  25295+49.2%
--
TOTAL   67 276084 169547 16954
  (estimated 10 runs per dumpcycle)

And it must be calculating the balance based on the original size, not 
the compressed size (out MB), that growing Tuesday the 20th is still on 
one vtape, but if unchanged, Thu 15nth will still use a 2nd vtape.

And from the emailed report, much less "churn". So I'm thinking we may 
have solved a goodly part of my planner complaints at the same time.
--
NOTES:
  planner: Incremental of coyote:/usr/local bumped to level 2.
  planner: Incremental of picnc:/ bumped to level 2.
  taper: tape Dailys-41 kb 26949743 fm 67 [OK]
---
And I woke up to recycle some water, so I'm going back to bed till a more 
civilized time of the day. :)

Copyright 2018 by Maurice E. Heskett
-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page