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*?

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        erics AT telepres DOT com
|  |  /
My Wine works.  However it crashes about half the time on startup.
Apparently their simulation of windoze API is getting too accurate.  :)
        - Kyle Sallee