On 01/26/2016 05:51 PM, Jean-Louis Martineau wrote: > What is the taperalgo setting?
largestfit >> 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
