On Wed, Aug 4, 2010 at 2:47 PM, Jean-Francois Malouin <ma...@bic.mni.mcgill.ca> wrote: > I think I am starting to understand but I'm still confused as to why > amdump uses the oldest newly labeled tape but then refuses to use the > second to last newly labelled tape. Also the fact the amreport says > that they should be used, and are in fact used by amflush when I flush > the hold disk.
No problem. This taperscan stuff *is* confusing. Part of the problem is that amreport basically "guesses" what tapes will be used next, since the actual taperscan algorithm requires tape movement and only produces one tape at a time. In many cases, it guesses wrong. > So I guess amdump would like av48-2_down_Q00040 which is not in > presently in the changer. Right? Correct. And it won't look for av48-2_down_Q00089, which is. However, failing to find av48-2_down_Q00040, it should fall back to stage 2 and start scanning sequentially. > BTW, the taper never scan all the slots (25-48) but only 25 to 36. > Is this correct? No, it's not. I'm rather confused as to why it would say that, in fact. > I think all of this mess is from a misconfig from my part: I must have > been living in sin all those years and never noticed it :) Sort of - that the taperscan's behavior depended on an implementation detail of the changer has been hidden for years. Things mostly work, and you only get surprised when you either use amlabel, start using autolabel, or switch to a searchable changer. So not quite living in sin, but taking advantage of an undocumented "feature". One thing that my help: you can force chg-robot to *pretend* to not be searchable (don't worry, it will still use the barcodes behind the scenes) by setting its FAST-SEARCH property to false. > It's not clear to me on how to change the taperscan algorithm. The manpage is a bit misleading, as at this point there's only one taperscan algorithm :( Dustin -- Open Source Storage Engineer http://www.zmanda.com
