On Wed, Dec 3, 2008 at 5:23 PM, Jeffrey D Anderson <[EMAIL PROTECTED]> wrote: > But somehow amanda chooses not to use that information. She just goes from > tape to tape, physically reading the on-tape labels, as though there were no > barcodes. I would have expected that amanda would determine the correct slot > based on the barcodes, and then would have verified the on-tape label. But > maybe I'm confused about what the expected behavior is.
Wow, now that I look at the code, you're right. What you're looking at, specifically, is the taperscan algorithm, which is triggered by taper (obviously), by amcheck (as you showed), and by 'amtape xx taper'. This algorithm was intended to search for a tape using the barcode reader, but do not do so in my testing, either. Smells like a bug to me! Here's the header comment in server-src/taperscan.c: 56 /* How does the taper scan algorithm work? Like this: 57 * 1) If there is a barcode reader, and we have a recyclable tape, use the 58 * reader to load the oldest tape. 59 * 2) Otherwise, search through the changer until we find a new tape 60 * or the oldest recyclable tape. 61 * 3) If we couldn't find the oldest recyclable tape or a new tape, 62 * but if in #2 we found *some* recyclable tape, use the oldest one we 63 * found. 64 * 4) At this point, we give up. 65 */ I'll get this fixed in the next 2.6.1 beta, at least so that the code does the above. Going forward into Changer API 2.0, I think we will need to modify the algorithm to make it a little bit to be more explicit about handling unlabeled tapes, etc. Dustin -- Storage Software Engineer http://www.zmanda.com
