On Thu May 15 2003 14:49, Eric Siegerman wrote:
>Hi, all.  A former Amanda user here, recently (like, in the last
>couple of weeks) returned to the fold.
>
>Ignoring the splitting-DLEs-across-multiple-tapes digression
>(*great* idea, but as has been pointed out, it's been discussed
>before)...
>
>On Thu, May 15, 2003 at 09:43:24AM +0200, Paul Bijnens wrote:
>> Maybe a refinement to taperalgo (extra option?) .
>> What should taperalgo decide when e.g.the tape is 50% full, here
>> are no files ready on holdingdisk that fit on the current tape,
>> but there are still DLE's to be dumped some of which will fit.
>> Should it wait for those DLE's (wasting time), should it skip to
>> the next tape (wasting tape)?  Or should it try the smallest
>> one, and hope it will fit (saving tape and time) or risk to run
>> into end of tape (wasting lots of time), or...
>
>What the code does now is basically:
>       switch (taper_algo) {
>               Using the configured algorithm, look for a DLE that:
>                 (a) is taper-ready
>                 (b) will fit on the current tape
>       }
>
>       if (the above didn't find a suitable DLE)
>               choose the first taper-ready DLE, regardless of size etc.
>
>I can think of a couple of useful improvements -- not sure how
>to make them all hang together, they're just off the top of my
>head:
>  - a separate config variable for a "second-chance" taper
>    algorithm (horrible name; suggestions most welcome).  The
>    choices would (to start with) be the same as the ones for the
>    main taper_algo, but they would all be weaker versions that
>    didn't take remaining tape into account -- just like the
>    implicit "weak FIRST" that's used now in the "if" statement
>
>    Intended usage:
>       taper_algo              LARGESTFIT
>       second_taper_algo       SMALLEST
>
>    One could emulate the current behaviour like this:
>       taper_algo              <whatever>
>       second_taper_algo       FIRST
>
>
>  - new options for second-taper-algo (not really useful for the
>    main one):
>      - NEWTAPE -- in other words, if there isn't currently a DLE
>       that will fit, change tapes rather than trying to dump a
>       too-large DLE
>
>      - SLOP n MB -- i.e. accept a DLE that exceeds the estimated
>       remaining tape by up to the specified amount.  Using this
>       as the main taper_algo seems equivalent to increasing the
>       tape length in the tapetype entry, but in the second-chance
>       position, it lets you say, in effect:
>           I think there are 2 GB left, so look for a DLE that's
>           smaller than that ... Darn, there aren't any; ok,
>           let's gamble, and hope there's really room for 2.2
>           GB.
>
>       One probably also wants a maximum DLE size to apply this
>       to -- I might be willing to bet the 15 min. of tape-drive
>       time for a 1-GB dump that's a little too big, but not
>       the several hours for a 10-GB dump.
>
>Orthogonal (I think!) to this stuff would be a way to say: wait
>until *all* of the dumps are in.  One of our Amanda configs does
>level-0's of everything for offsite storage (with "record no").
>We have enough holding-disk space to hold the lot, so if the
>taping didn't start until all of the dumps were finished (and so
>all of their sizes were known), that would let LARGESTFIT do a
>better job of packing tapes, and might save a tape some of the
>time.
>
>P.S.: "DLE" is a new acronym since the last time I used Amanda in
>1998.  I believe I've been able to infer what it means, but what
>does it *stand for*?
>
DLE=DiskList Entry

>My Wine works.  However it crashes about half the time on startup.
>Apparently their simulation of windoze API is getting too
> accurate.  :) - Kyle Sallee

Chuckle...

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.