A NOTE has been added to this issue.
======================================================================
http://bugs.bacula.org/view.php?id=1252
======================================================================
Reported By: N2
Assigned To:
======================================================================
Project: bacula
Issue ID: 1252
Category: bconsole
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
======================================================================
Date Submitted: 2009-03-19 11:09 GMT
Last Modified: 2009-03-31 17:46 BST
======================================================================
Summary: Eject Tape : InChanger flag not reset to 0 after an
Update Slot
Description:
Hi,
I am using bacula-2.4.4 and bweb.
I have autochanger Dell ML6000 with barcodes.
Everything is working well, but when I remove a tape from the library,
next I launch an "update slot" the InChanger flag is still set to 1.
So, how can I fix this issue ? Maybe it's not the good way to run an
"Update slot" to change the Inchanger flag ?
Currently, when I remove a tape, I have to change the Inchanger Flag
manually.
So, I would like to know if there is a way to do that automatically using
update slot or something else ?
Thanks in advance for your recomandation.
Mathieu
======================================================================
----------------------------------------------------------------------
(0004028) ebollengier (developer) - 2009-03-19 12:11
http://bugs.bacula.org/view.php?id=1252#c4028
----------------------------------------------------------------------
Your problem looks like http://bugs.bacula.org/view.php?id=1175
Depending on your configuration you could have problem if you have
multiple drives.
----------------------------------------------------------------------
(0004029) N2 (reporter) - 2009-03-19 12:33
http://bugs.bacula.org/view.php?id=1252#c4029
----------------------------------------------------------------------
Thanks for your quick feedback.
But I'm using the bacula version 2.4.4, so normally, according with your
last entry this bug should be fixed with the bacula version 2.4.4.
But maybe we have to apply this patch : 1175-unique-inchanger.patch ?
Could you please confirm ?
----------------------------------------------------------------------
(0004030) ebollengier (developer) - 2009-03-19 12:57
http://bugs.bacula.org/view.php?id=1252#c4030
----------------------------------------------------------------------
No, this patch reset the Slot attribute at the same time than the InChanger
flag.
I've run a test with the latest 2.4 version, and the InChanger flag has
the right behavior. Don't forget that Bacula doesn't support very well
multiple drive autochanger with direct access.
If you aren't in this case, you can attach director/storage configuration
and complete outputs of "llist volume=xxx", "show storage" and your update
slots command.
----------------------------------------------------------------------
(0004038) N2 (reporter) - 2009-03-20 11:02
http://bugs.bacula.org/view.php?id=1252#c4038
----------------------------------------------------------------------
Hi,
Thanks for your advice.
In fact, we use multiple drives (2) autochanger with direct access. (dell
ML6000)
So, currently we remove a tape using the menu of the ML6000, next we run
an update slot. According with you last entry it seems that Bacula doesn't
support very well this method.
So, we tried using bweb and the command "eject" in the autochanger menu.
Then, the tape is stored in the magazine of the autochanger, next we eject
manually the tape, run an "update slot" but still the same issue with the
Inchanger flag.
With this method, there is no direct access with the autochanger.
Do you have any idea to help us ?
----------------------------------------------------------------------
(0004045) kern (administrator) - 2009-03-20 17:49
http://bugs.bacula.org/view.php?id=1252#c4045
----------------------------------------------------------------------
You will need to give more exact information -- i.e. exactly what command
you are using. There is no such command "update slot". Please include
before llist Volumes and after llist Volumes as well as the console output.
----------------------------------------------------------------------
(0004062) N2 (reporter) - 2009-03-23 14:05
http://bugs.bacula.org/view.php?id=1252#c4062
----------------------------------------------------------------------
Hi kern,
In fact we are using the command update slots as mentionned in bacula's
manual.
See below:
The update slots command will first obtain the list of cassettes and their
barcodes from mtx-changer. Then it will find each volume in turn in the
catalog database corresponding to the barcodes and set its Slot to
correspond to the value just read. If the Volume is not in the catalog,
then nothing will be done. This command is useful for synchronizing Bacula
with the current magazine in case you have changed magazines or in case you
have moved cassettes from one slot to another.
Then, to illustrate our issue, you can find below
- a command llist which show that the tape 24 (id 40) in the changer.
- then we remove this tape from the autochanger and run an "update slots"
The command do not talk about the tape 24 (so it confirms that the tape is
not in the autochanger)
- then the command llist volumes show that the inchanger flag is still set
to 1
*llist volumes
Pool: PCpool
....skip....
MediaId: 24
VolumeName: 000015
Slot: 23
PoolId: 1
MediaType: LTO4
FirstWritten: 0000-00-00 00:00:00
LastWritten: 0000-00-00 00:00:00
LabelDate: 2009-02-13 13:58:29
VolJobs: 0
VolFiles: 0
VolBlocks: 0
VolMounts: 0
VolBytes: 64,512
VolErrors: 0
VolWrites: 0
VolCapacityBytes: 0
VolStatus: Append
Enabled: 1
Recycle: 1
VolRetention: 7,776,000
VolUseDuration: 0
MaxVolJobs: 0
MaxVolFiles: 0
MaxVolBytes: 0
InChanger: 1
EndFile: 0
EndBlock: 0
VolParts: 0
LabelType: 0
StorageId: 2
DeviceId: 0
LocationId: 6
RecycleCount: 0
InitialWrite: 0000-00-00 00:00:00
ScratchPoolId: 0
RecyclePoolId: 1
Comment:
... skip ...
Pool: Scratch
No results to list.
*update slots
The defined Storage resources are:
1: APOLLONUS
2: APOLLONUS-Monitoringbck
3: APOLLONUS-Internalbck
4: APOLLONUS-Backendbck
5: APOLLONUS-Publicbck
6: APOLLONUS-Securitybck
7: APOLLONUS-Satdatabck
8: APOLLONUS-Voipbck
9: APOLLONUS-Monitoring
10: APOLLONUS-Intranet
11: APOLLONUS-GemaltoDasbck
12: APOLLONUS-AresPartenorddatabck
13: APOLLONUS-AresPartenordadminbck
14: APOLLONUS-CRPCDTCappbck
15: APOLLONUS-CRPCDTCdatabck
Select Storage resource (1-15): 1
Enter autochanger drive[0]:
Connecting to Storage daemon APOLLONUS at 192.168.1.95:9103 ...
3306 Issuing autochanger "slots" command.
Device "APOLLONUS" has 34 slots.
Connecting to Storage daemon APOLLONUS at 192.168.1.95:9103 ...
3306 Issuing autochanger "list" command.
Catalog record for Volume "000005" updated to reference slot 1.
Catalog record for Volume "000006" updated to reference slot 2.
Catalog record for Volume "000020" updated to reference slot 3.
Catalog record for Volume "000002" updated to reference slot 5.
Catalog record for Volume "000009" updated to reference slot 6.
Catalog record for Volume "000007" updated to reference slot 7.
Catalog record for Volume "000001" updated to reference slot 8.
Catalog record for Volume "000011" updated to reference slot 9.
Catalog record for Volume "000017" updated to reference slot 11.
Catalog record for Volume "000013" updated to reference slot 12.
Catalog record for Volume "000014" updated to reference slot 13.
Catalog record for Volume "000012" updated to reference slot 14.
Catalog record for Volume "000023" updated to reference slot 15.
Catalog record for Volume "000022" updated to reference slot 16.
Catalog record for Volume "000003" updated to reference slot 17.
Catalog record for Volume "000021" updated to reference slot 19.
Catalog record for Volume "000019" updated to reference slot 20.
Catalog record for Volume "000016" updated to reference slot 22.
Catalog record for Volume "000015" updated to reference slot 23.
Catalog record for Volume "000026" updated to reference slot 24.
Catalog record for Volume "000025" updated to reference slot 25.
Catalog record for Volume "000008" updated to reference slot 4.
Catalog record for Volume "000018" updated to reference slot 10.
*llist volumes
...skip....
MediaId: 24
VolumeName: 000015
Slot: 23
PoolId: 1
MediaType: LTO4
FirstWritten: 0000-00-00 00:00:00
LastWritten: 0000-00-00 00:00:00
LabelDate: 2009-02-13 13:58:29
VolJobs: 0
VolFiles: 0
VolBlocks: 0
VolMounts: 0
VolBytes: 64,512
VolErrors: 0
VolWrites: 0
VolCapacityBytes: 0
VolStatus: Append
Enabled: 1
Recycle: 1
VolRetention: 7,776,000
VolUseDuration: 0
MaxVolJobs: 0
MaxVolFiles: 0
MaxVolBytes: 0
InChanger: 1
EndFile: 0
EndBlock: 0
VolParts: 0
LabelType: 0
StorageId: 2
DeviceId: 0
LocationId: 6
RecycleCount: 0
InitialWrite: 0000-00-00 00:00:00
ScratchPoolId: 0
RecyclePoolId: 1
Comment:
...skip...
Pool: Scratch
No results to list.
*
Is that more clear for you ?
----------------------------------------------------------------------
(0004063) ebollengier (developer) - 2009-03-23 14:11
http://bugs.bacula.org/view.php?id=1252#c4063
----------------------------------------------------------------------
As you can see, the StorageId is 2, and i'm 99% sure that the storage
"APOLLONUS" as StorageId=1 (you miss the show storage command as i asked
before)
So, when you update slots, you will reset empty slots only for media with
StorageId=1 (ie nothing).
----------------------------------------------------------------------
(0004064) N2 (reporter) - 2009-03-23 15:39
http://bugs.bacula.org/view.php?id=1252#c4064
----------------------------------------------------------------------
Hello,
Sorry for the missing command:
Here the result.
Storage: name=APOLLONUS address=x.x.x.x SDport=9103 MaxJobs=8
DeviceName=APOLLONUS MediaType=LTO4 StorageId=2
Storage: name=APOLLONUS-Monitoringbck address=x.x.x.x SDport=9103
MaxJobs=8
DeviceName=APOLLONUS MediaType=LTO4 StorageId=5
Storage: name=APOLLONUS-Internalbck address=x.x.x.x SDport=9103 MaxJobs=5
DeviceName=APOLLONUS MediaType=LTO4 StorageId=6
Storage: name=APOLLONUS-Backendbck address=x.x.x.x SDport=9103 MaxJobs=8
DeviceName=APOLLONUS MediaType=LTO4 StorageId=7
Storage: name=APOLLONUS-Publicbck address=x.x.x.x SDport=9103 MaxJobs=5
DeviceName=APOLLONUS MediaType=LTO4 StorageId=8
Storage: name=APOLLONUS-Securitybck address=x.x.x.x SDport=9103 MaxJobs=5
DeviceName=APOLLONUS MediaType=LTO4 StorageId=9
Storage: name=APOLLONUS-Satdatabck address=x.x.x.x SDport=9103 MaxJobs=5
DeviceName=APOLLONUS MediaType=LTO4 StorageId=10
Storage: name=APOLLONUS-Voipbck address=x.x.x.x SDport=9103 MaxJobs=8
DeviceName=APOLLONUS MediaType=LTO4 StorageId=11
Storage: name=APOLLONUS-Monitoring address=x.x.x.x SDport=9103 MaxJobs=8
DeviceName=APOLLONUS MediaType=LTO4 StorageId=4
Storage: name=APOLLONUS-Intranet address=x.x.x.x SDport=9103 MaxJobs=15
DeviceName=APOLLONUS MediaType=LTO4 StorageId=17
Storage: name=APOLLONUS-xxxbck address=x.x.x.x SDport=9103 MaxJobs=5
DeviceName=APOLLONUS MediaType=LTO4 StorageId=12
Storage: name=APOLLONUS-xxxx address=x.x.x.x SDport=9103 MaxJobs=5
DeviceName=APOLLONUS MediaType=LTO4 StorageId=13
Storage: name=APOLLONUS-xxxadminbck address=x.x.x.x SDport=9103 MaxJobs=5
DeviceName=APOLLONUS MediaType=LTO4 StorageId=14
Storage: name=APOLLONUS-xxxappbck address=x.x.x.x SDport=9103 MaxJobs=5
DeviceName=APOLLONUS MediaType=LTO4 StorageId=15
Storage: name=APOLLONUS-xxxdatabck address=x.x.x.x SDport=9103 MaxJobs=5
DeviceName=APOLLONUS MediaType=LTO4 StorageId=16
So, APOLLONUS has the storage id 2. So, it should work, no ?
I have an additionnal question:
In normal conditions, do we have to run an "update slots" for each storage
?
Because we have some taped with different Storage ID.
If yes, is there an other way to update these Inchanger flags ?
----------------------------------------------------------------------
(0004065) kern (administrator) - 2009-03-23 16:10
http://bugs.bacula.org/view.php?id=1252#c4065
----------------------------------------------------------------------
Thanks for the info. We would like to understand the problem just a bit
more, before giving any advice for fixing it.
1. Would you upload your bacula-sd.conf and your bacula-dir.conf files?
Please be sure to zap your passwords.
2. Have you modified your Storage definition for APOLLONUS after running
some backups?
3. Please run the following commands in bconsole and attach the output:
sql
select * from Storage;
4. Please re-run your update slots command, but as follows:
setdebug level=100 dir
update slots
...
setdebug level=0 dir
It should generate additional debug output that we would like to see.
Thanks.
----------------------------------------------------------------------
(0004074) N2 (reporter) - 2009-03-26 12:05
http://bugs.bacula.org/view.php?id=1252#c4074
----------------------------------------------------------------------
Hello,
I uploaded requested files.
For the point 2, yes we modified it:
Old storage :
< Name = APOLLONUS
< Device = Drive-1
< Device = Drive-2
---
Current storage :
> Name = "APOLLONUS"
> Device = Drive-1, Drive-2
> # Device = Drive-2
Thanks a lot for your help.
----------------------------------------------------------------------
(0004075) ebollengier (developer) - 2009-03-26 13:03
http://bugs.bacula.org/view.php?id=1252#c4075
----------------------------------------------------------------------
I don't see any debug output, in your debug file. You can try to use
setdebug trace=1 level=100 director and attach the trace file located in
the
working directory.
----------------------------------------------------------------------
(0004085) kern (administrator) - 2009-03-31 17:46
http://bugs.bacula.org/view.php?id=1252#c4085
----------------------------------------------------------------------
As Eric says there is no debug output, so debug is probably turned off in
your binary.
It appears that you are referencing the autochanger through a large number
of "aliases" that is you are referencing it at many different IP addresses,
with different names, but it is always the same autochanger.
Bacula currently assumes that each Storage resource points to a physically
different device, so I am not too surprised that it is confused.
Basically, you are using a configuration that is not really supported.
At this point, I think you will either need to figure it out by yourself
or possibly get professional help as this is not a simple problem. It has
to do with the way you are using Bacula and the aliases -- probably due to
your internal network configuration.
I am going to close this bug because it seems to me to go far beyond
Bacula's current capabilities.
To solve your immediate problem, you will probably need to do some
"manual" SQL commands to clean up your database ...
Issue History
Date Modified Username Field Change
======================================================================
2009-03-19 11:09 N2 New Issue
2009-03-19 12:11 ebollengier Note Added: 0004028
2009-03-19 12:33 N2 Note Added: 0004029
2009-03-19 12:57 ebollengier Note Added: 0004030
2009-03-20 11:02 N2 Note Added: 0004038
2009-03-20 17:49 kern Note Added: 0004045
2009-03-20 17:49 kern Status new => feedback
2009-03-23 14:05 N2 Note Added: 0004062
2009-03-23 14:11 ebollengier Note Added: 0004063
2009-03-23 15:39 N2 Note Added: 0004064
2009-03-23 16:10 kern Note Added: 0004065
2009-03-26 12:03 N2 File Added: bacula-dir.conf
2009-03-26 12:04 N2 File Added: bacula-sd.conf
2009-03-26 12:04 N2 Issue Monitored: N2
2009-03-26 12:04 N2 File Added: debug-and-sql.log
2009-03-26 12:05 N2 Note Added: 0004074
2009-03-26 13:03 ebollengier Note Added: 0004075
2009-03-31 17:46 kern Note Added: 0004085
======================================================================
|