[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amanda-users
Subject:    Re: amcheck does not recognize lablestr
From:       Jean-Louis Martineau <martineau () zmanda ! com>
Date:       2013-01-07 18:01:45
Message-ID: 50EB0D89.2080705 () zmanda ! com
[Download RAW message or body]

On 01/07/2013 09:06 AM, Dennis Benndorf wrote:
> Hello Jean-Louis,
>
> it seems to be my fault. We moved tapes from one roboter to the other, 
> not ivoking "amtape daily inventory", so 
> /usr/local/var/amanda/chg-robot-dev-CHANGER had wrong tape 
> information. I thought "the tapechanger" would ivoke mtx status to 
> poll information about tape status, but it does only change this file 
> if a tape is read or if "amtape daily inventory" is ivoked. It think 
> this also affects my other email.

amanda update its state file every time the changer is used.
With barcode, amanda know exactly which tape is loaded.
Without barcode, amanda can't know if you changed the tape of some slot, 
so it keep the old information in its state file, you must:
    amtape daily update 20-25     #amanda will read the tape in slot 20 
to 25 and update its state file.
    amtape daily update 20-25=  #amanda mark them as unknown, it will 
read them if it can't find other tape to write to.
    amtape daily update 20=D01234  #The tape with label D01234 is load 
in slot 20.

Jean-Louis
>
> Sorry for the noise ...regards,
> Dennis
>
>
>
> Am 07.01.2013 14:48, schrieb Jean-Louis Martineau:
>> Dennis,
>>
>> The attached patch fix the traditional taperscan bug.
>>
>> It's hard to say what's wrong with the oldest taperscan without more 
>> information:
>>   - the debug files
>>   - the changet state file
>>   - the output of: mtx -f /dev/sg?? status
>>
>> Jean-Louis
>>
>> On 01/07/2013 05:00 AM, Dennis Benndorf wrote:
>>> Hello,
>>>
>>> I am using Amanda version 3.3.2.svn.5082 with labelstr "^D0[0-9]*$". 
>>> In Tapelist there are tapes starting with D0 and D1. These tapes are 
>>> in different libraries and are vaulted with amvault.
>>>
>>> Now that the taperscan "oldest" does not really seam to work for us 
>>> anylonger ( it moans about no acceptable volumes found ), I change 
>>> taperscan to traditional and got this messages:
>>>
>>> amanda@dl380-54:~$ amcheck -t daily
>>> Amanda Tape Server Host Check
>>> -----------------------------
>>> Searching for label 'D10234': label 'D10234' not recognized or not 
>>> found
>>> slot 129: volume 'D00235' is still active and cannot be overwritten
>>> slot 130: volume 'D00192' is still active and cannot be overwritten
>>> slot 131: volume 'D00193' is still active and cannot be overwritten
>>> slot 132: volume 'D00075'
>>> Will write to volume 'D00075' in slot 132.
>>> NOTE: skipping tape-writable test
>>> Server check took 221.838 seconds
>>>
>>> As you can see, it would like to have a D1 tape but lablestr is 
>>> "^D0[0-9]*$". This is a robot with nearly 700 tapes in it. 
>>> Sequentail scanning might take some time, in worst case....
>>>
>>> Regards,
>>> Dennis
>>>
>>> P.S. What might be wrong that taperscan "oldest", which is the 
>>> better scan-algorithm I think, does not find the tapes, but 
>>> taperscan "traditional" does?
>>
>

[prev in list] [next in list] [prev in thread] [next in thread]