On Wed, Dec 3, 2008 at 5:23 PM, Jeffrey D Anderson <JDAnderson AT lbl DOT gov> 
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