View Full Version : chg-robot changer and fast search

March 29th, 2010, 02:56 AM
Hello- I wanted to test the "chg-robot" changer in Amanda 3.1x because I could never get "chg-zd-mtx" to do fast-search right in 2.6. Unfortunately, I am having similar problems with 3.1.x, and I was hoping someone could tell me what I'm doing wrong. Background:

* Downloaded latest 3.1 tarball available as of last Friday (3/26).
* Built RPM for Red Hat Enterprise Linux 5.3 (had to make several changes to the spec file for the build and install to complete, but now installs without error)
* Using an Hewlett-Packard MSL4048 tape library connected via fiber channel
* Tape library has LTO4 Ultrium tape drive (created a custom tapetype after testing with amtapetype)

Symptoms: When amcheck or amdump run, and a tape with the right label is already in the drive, then all is well. If it's not, then they appear to ignore the "barcode-2-label" info in the state file, and go into some sort of "stacker" mode, sequentially hunting through the slots until a suitable tape label is found.

However, running "amtape <config> label <label>" works as I would expect, loading the correct tape right away with no hunting. That is, if the current slot is #4, and the label I specify to amtape is in slot 20, then it unloads the drive back to slot 4, and immediately loads slot 20. When I setup this same experiment for amcheck or amdump, it unloads the current tape to slot 4, and the loads 5, 6, 7, ... until it gets to slot 20. Ew.

Once amdump finally gets to a slot with a correct tape label, then it uses that tape, writing to the tape, and the job completes without error. Any ideas?


BTW, here is my hardware configuration from amanda.conf:

define changer HP-MSL4048 {
tpchanger "chg-robot:/dev/changer"
changerfile "/etc/amanda/HP-MSL4048.state"
property "fast-search" "yes"
# library just has one tape drive
property "tape-device" "0=tape:/dev/nst0"
property "eject-before-unload" "no"
property "status-interval" "0"
# Default timing
property "load-poll" "0 s poll 3 s until 120 s"
# Cleaning cartridge in slot 21. Library autoclean is on.
property "use-slots" "1-20"
#tapedev "HP-MSL4048" # Tried both ways
tpchanger "HP-MSL4048"

# Tape drive installed in HP MSL4048 tape library
define tapetype HP-LTO4 {
comment "hardware compression on"
length 772096 mbytes
filemark 0 kbytes
speed 101427 kps
tapetype HP-LTO4 # what kind of tape it is

March 29th, 2010, 03:11 AM
Post the amcheck.*.debug file

March 29th, 2010, 11:51 AM
I have attached the amtape.*.debug file from when I issued the command "amtape Daily1 label Daily1-01". This seems to work fine regarding fast-search, loading the correct tape immediately, regardless of what the "current slot" is set to.

I have also attached the "amcheck*.debug" and "amcheck-device*.debug" files from the subsequent amcheck command. Fast-search fails here, starting a sequential stacker-type hunt. Here is the stdout from the command:

[amanda@slot15_6014 amanda]$ amcheck Weekly1
Amanda Tape Server Host Check
slot 1: volume 'Daily1-01' does not match labelstr '^Weekly1-[0-9]*$'
slot 2: volume 'Daily1-02' does not match labelstr '^Weekly1-[0-9]*$'
slot 3: volume 'Daily1-03' does not match labelstr '^Weekly1-[0-9]*$'
slot 4: volume 'Daily1-04' does not match labelstr '^Weekly1-[0-9]*$'

At this point, I take pity on my tape drive loader mech, and Ctrl-C...

Thank you,

March 29th, 2010, 01:59 PM
In amcheck-device.*.debug: Amanda::Taper::Scan::traditional no oldest reusable volume

amcheck and amdump can only locate by label the oldest reusable volume.
A reusable volume is a volume already used by this amanda config.

March 29th, 2010, 02:49 PM
OK, thanks for the reply. Amdump and amcheck giving priority to loading LRU tape volumes makes perfect sense. Are there any plans to allow these programs to locate by label when there is no LRU present? (as amtape does)

When working with a midsize to large libraries (ours is 48 slots), a new backup job could load 47 tapes just to write one. This is irksome when all the information is there in the state file to avoid doing this.

I guess I could look at tapelist before running amcheck and amdump, and if there is no LRU, then I could use amtape to pre-load a tape from the correct label pool. Does that make sense?

FYI, I am an old hand at Unix, Linux, and system integration, but I am a newbie to Amanda.


March 29th, 2010, 03:05 PM
We have plan to improve it.

Loading the correct tape prior to amcheck/amdump is good way to do it.

March 30th, 2010, 09:31 AM
OK, that's nice to hear. Let me know if I can help in any way, such as testing. Thanks for your time and answers.
-Austin (regaug)

April 12th, 2010, 09:39 PM
When working with a midsize to large libraries (ours is 48 slots), a new backup job could load 47 tapes just to write one. This is irksome when all the information is there in the state file to avoid doing this.

cissp (http://www.cissplearn.com)