I figured out question #2. I had 2 of the drives in my changer config setup wrong. I had forgotten that I was never able to get my drive device number match the drive slot numbers that mtx returned. So, when amtape would load a tape into drive 4 it was configured to then access /dev/nst4 and drive 5 to /dev/nst5, but drive 4 is really /dev/nst5 and vice versa. So, some percentage of my inventory is completely off. I've fixed the config and will need to update the whole thing. Going through all this has made me want to suggest a couple of changes to the way the code works. 1. It would be nice if the amtape inventory command could just return its data from the state file. It looks like it is doing a mtx status which for some reason takes a long time for me. I just want an easy way to see where amanda thinks everything is in a parsed format. 2. It would be nice if the amtape update command would output the information that it found when it finishes checking each slot. This wouldn't have been a big deal if the inventory didn't take so long, but each time a run update on a single slot I have to run an inventory to see what it found there to know if I was on the right track.
Thanks, Mike On Jul 23, 2010, at 1:15 PM, Dustin J. Mitchell wrote: > On Fri, Jul 23, 2010 at 2:07 PM, Michael Robbert <[email protected]> wrote: >> 1. How can we fix the fatal error? I'm more than willing to help debug if >> this doesn't appear to be reproducible. I'm a capable Linux system >> administrator that knows a little perl, but not a developer. > > I'll see if I can reproduce it. SWIG-related error messages can be > fantastically irritating, because they only contain the first few > characters of the symbol causing the problem -- in this case, > swig_header_<something>. It's most likely a typo, so hopefully it > will turn up with a careful reading. > >> 2. Any thoughts on why my changer inventory appears to be off so much? I >> have resorted to running updates on small chunks of my library to find >> tapes, but I've hit the problem even then. The library has 188 slots and a >> full update takes many hours. > > This, I do not know. Is there something else that is moving tapes > around in the library? Note that you can find Amanda's impression of > where things are with 'amtape inventory'. Can you compare that to > reality (using the barcodes, maybe?) and see if there's a pattern? > Also, the state file for the changer is just a perl data structure, so > it's human-readable, if you want to take a look at what Amanda's > mapping of barcodes to labels looks like. > > Dustin > > -- > Open Source Storage Engineer > http://www.zmanda.com
