On Thursday 15 November 2018 14:17:29 Austin S. Hemmelgarn wrote: > On 2018-11-15 13:36, Gene Heskett wrote: > > On Thursday 15 November 2018 12:57:54 Austin S. Hemmelgarn wrote: > >> On 2018-11-15 11:53, Gene Heskett wrote: > >>> On Thursday 15 November 2018 07:36:37 Austin S. Hemmelgarn wrote: > >>>> On 2018-11-15 06:16, Gene Heskett wrote: > >>>>> I ask because after last nights run it showed one huge and 3 > >>>>> teeny level 0's for the 4 new dle's. So I just re-adjusted the > >>>>> locations of some categories and broke the big one up into 2 > >>>>> pieces. "./[A-P]*" and ./[Q-Z]*", so the next run will have 5 > >>>>> new dle's. > >>>>> > >>>>> But an estimate does not show the new names that results in. > >>>>> I've even took the estimate assignment calcsize back out of the > >>>>> global dumptype, which ack the manpage, forces the estimates to > >>>>> be derived from a dummy run of tar, didn't help. > >>>>> > >>>>> Clues? Having this info from an estimate query might take a > >>>>> couple hours, but it sure would be helpfull when redesigning > >>>>> ones dle's.I'm fairly certain you can't, because it specifically > >>>>> shows server-side > >>>> > >>>> estimates, which have no data to work from if there has never > >>>> been a dump run for the DLE. > >>> > >>> Even if you told it to user tar for the estimate phase? That has > >>> enough legs to be called a bug. IMO anyway. > >> > >> As mentioned in one of my other responses, I can kind of see the > >> value in this not bothering the client systems. Keep in mind that > >> server estimates cost nothing on the client, while calcsize or > >> client estimates may use a significant amount of resources. > > > > My default has been calcsize for three or 4 years, changed because > > tar was changed & was screwing up the estimates. I can remember 15+ > > years ago when I was using real tar estimates, on a much smaller > > machine, and it could come within 50 megabytes of filling a DDS-2 > > tape (4 GB compressed) for weeks at a time. So that part of amanda > > worked a lot better than it does today. And its slowly gone to the > > dogs as my system grew in complexity. And went in a handbasket when > > I had to change to calcsize during the tar churn. > > I've not been using AMANDA anywhere near as long as you have, but I've > actually not seen any issues with accuracy of 'estimate client' mode > estimates with current versions of GNU tar, except when the estimate > ran while data in the DLE was being modified (and in that case, it > makes sense that it would be bogus).
Absolutely, but I don't make it a habit to start downloading install iso's when amanda is about to run. > I generally don't 'estimate > client' on my own systems though because it consistently takes far > longer than 'estimate calcsize', and I'm not picky about the estimates > being perfect. > > >> In this case, I do think the documentation should be a bit clearer, > > > > Yes, but who is to rewrite it? He should know a heck of a lot more > > than I do about the amanda innards than I do even after 2 decades, > > and better defined words here and there too. diakdevice is a very > > poor substitute for the far more common slanguage of "/path/to/" > > > >> and it would be useful to be able to get regular (calcsize and/or > >> client) estimates on-demand, but I do think that the default is > >> reasonably sane. > > > > It may well be sane, we'll see how it works in the morning. AIUI, > > calcsize runs only on old history. so that should not impinge a load > > on the client, even when the client is itself. > > Unless I'm mistaken: > > * 'estimate server' runs only on historical data, and doesn't even > talk to the client systems. It's good at limiting the impact the > estimate has on the client, but reliably gives bogus estimates if your > DLEs don't show consistent behavior (that is, each backup of a given > level is roughly the same size as every other backup at that level). > * 'estimate client' relies on the backup program being used to give it > info about how big it will be. It gives estimates that are close to > 100% accurate, but currently essentially requires running the backup > process twice (once for the estimate, once for the actual backup) and > imposes a non-negligible amount of load on the client. > * 'estimate calcsize' does something kind of in-between. AIUI, it > looks at some historical data, and also looks at the on-disk size of > the data, then factors in compression ratios and such to give an > estimate that's usually reasonably accurate without needing the DLEs > to be consistent or imposing significant load on the clients. Copyright 2018 by Maurice E. Heskett -- Cheers everybody, 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 <http://geneslinuxbox.net:6309/gene>
