On Wed, Jan 27, 2016 at 03:39:39PM -0500, Jean-Louis Martineau wrote: > On 27/01/16 11:47 AM, jflack wrote: > >On 01/26/2016 05:51 PM, Jean-Louis Martineau wrote: > > > >>What is the taperalgo setting? > >largestfit > > man amanda.conf: > largestfit > The largest dump image that will fit on the current tape. > > The full dump is too large to fit on the tape, so amanda flush a smaller > dump (the incrementals). > > You found a bug, amanda must always flush dump in datestamp order!!
You mean within a group of the same DLE dumps or datestamp order among all available dumps? > > Jean-Louis > > > >>> Dumps: lev datestmp tape file origK compK secs > >>> 0 20160124 0 20550680 20550680 369 > >>> 1 20160125 0 680 680 11 > >>> 2 19691231 D03001 69 0 0 0 > >>That one looks like a bug. I suspect it is an old dump that was deleted > >>when D03001 was overwritten. > >I think there might be an arguable bug of some kind, but I see > >situations like this frequently in amadmin info output ... that > >is, two situations that are similar: > > > >1. A full dump that is still in the holding disk, with a later > > increment that has been taped, where the later increment has > > nonzero size and a real datestmp > > > >2. A full dump that is still in the holding disk, with a later > > increment that has zero size (probably nothing changed in > > that DLE), and a 19691231 datestmp. > > > >It looks to me as if the 19691231 datestmp (Unix epoch, depending > >on your timezone) is always what appears if the increment has > >zero size. That seems like a quirky-but-minor issue. > > > >What holds more of my interest is this apparent pattern where > >increments will go to tape even before the full dumps they > >depend on, with the full dump not necessarily even going to > >tape until a later amflush. > > > >When I look at the list of available taperalgos, it looks as if > >they only consider two things: dump size (largest, smallest, > >any algo ending with "fit"), and time of dump completion > >(first, last, any algo starting with "first"). > > > >I don't see that any algo explicitly considers the dependency > >relationships between dumps (hmm, dump B *depends on* dump A, > >so I should satisfy the stated algo preferences in a way > >that also makes sure A is on tape if B is). > > > >As a practical matter, dump A must have arrived at the holding > >disk before dump B did, so algo "first" will probably DTRT, > >and "firstfit" will probably DTRT most of the time. Algo "last" > >will probably DTRT only when no other outcome is possible. :) > > > >I guess what I'm wondering is, how straightforward is the > >development of additional taperalgos? Can they be written > >in Perl? Is there an API for retrieving information on the > >dumps that are in the holdingdisk, and enough information to > >figure out which ones *depend on* which others, so something > >like a topological sort could be done? > > > >And ... is there anybody already working on that? > > > >-Chap >>> End of included message <<< -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
