Menu
▾
▴
[Bacula-bugs] [bacula 0001128]: InChanger flag set/unset at wrong media
|
From: <bac...@li...> - 2008-08-25 15:01:15
|
A NOTE has been added to this issue. ====================================================================== http://bugs.bacula.org/view.php?id=1128 ====================================================================== Reported By: slehmann Assigned To: ====================================================================== Project: bacula Issue ID: 1128 Category: Director Reproducibility: always Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 07-25-2008 09:17 BST Last Modified: 08-25-2008 16:01 BST ====================================================================== Summary: InChanger flag set/unset at wrong media Description: There are two autochanger: 1. one virtual for file-devices named "File", virtual slots 1 to 22 with barcodes 00100 to 00122. 2. one physical autochanger (named SL-500), physical slots 1 to 100, barcodes 000200 to 000299. if on the virtual changer a volume is beeing used, e.g. the vol 101 at slot 1 (virtual), the inchanger flag at volume 201 at slot 1 (physical) is unset. The slot number of both volumes is the same but the locations/autochangers are different. ====================================================================== ---------------------------------------------------------------------- kern - 07-26-08 07:05 ---------------------------------------------------------------------- Normally the InChanger flag is only cleared when there is an error reading a volume, and it is only set either manually or during a label or scan, so with what you have described, I seen no reason for the InChanger flag to change during a job. Although, possibly there is a bug in the reading code that attempts to incorrectly update the InChanger code ... If you would like us to look at this further, please supply the following: 1. A listing of all the volumes involved showing the InChanger flag probably a "list volume=xxx" will suffice. 2. Run your backup jobs and provide full output with *all* messages. 3. Another listing of all the volumes involve showing the InChanger flag has changed. ---------------------------------------------------------------------- slehmann - 07-29-08 07:18 ---------------------------------------------------------------------- I will provide you the informations as soon as possible, but this could be quite complicate for me because of the big environment. ---------------------------------------------------------------------- slehmann - 08-05-08 19:25 ---------------------------------------------------------------------- Ok, it looks like i have seen the problem in action. I have attached three files "list volumes.txt","stat dir.txt" and "stat sd.txt". As you can see in stat dir and stat sd one job is running backing up a computer. This backup job is using volume 00122. In list volumes you see that the inchanger-flag is set to 0 an the slot also. But the inchanger flag of volume 000221 is set to 0, too. This should be set to 1. The migration job is using different volumes, but there the inchanger flags are set and the slot numbers are correct. ---------------------------------------------------------------------- slehmann - 08-04-08 16:27 ---------------------------------------------------------------------- After the backup is finished, the inchanger-flag of volume 00122 is set and slot nummer 22 is inserted. But the inchanger-flag of volume 000121 at slot 22 is not set, as you can see in "list volumes 2.txt" (attached). ---------------------------------------------------------------------- kern - 08-05-08 19:52 ---------------------------------------------------------------------- I am having a hard time understanding what is going wrong. I see: - A job is reading Volume 122 - On one output Volume 122 has inchanger and slot both 0, and Volume 221 has slot 22 and Inchanger 0. - On another output Volume 122 has slot 22 and inchanger 1 and Volume 221 has slot 22 and Inchanger 0. If you want the autochangers to work, those settings are not very good for either volume 122 nor volume 221, but I don't know when those outputs were made or the relation they have to the migration job. Even if they have some relationship, volume 221 always has Inchanger 0. I can assume that list_volumes.txt was made before the job and list_volumes_2.txt was made after, but without seeing the job output it doesn't help much. You will need to be a lot more specific about when these things are happening. Before I can track down a problem, I need to see: - Before some action, everything is OK - Make some action (e.g. migration) - Show the full job output of the action - Show that things are messed up. One thing from your output that surprises me is the Bacula DIR heap size which is almost 3MB. Do you have any idea why it is so large -- that does not seem normal to me -- it indicates a problem with your database, or that Bacula is inserting the attributes when the listing was made. Are you sure you are running the same version of the DB that corresponds to the header and library files that were available when Bacula was built? Please don't attach files with names containing spaces -- it makes it much harder to access them. Thanks. ---------------------------------------------------------------------- slehmann - 08-11-08 09:34 ---------------------------------------------------------------------- Ok, sorry for my inapprehensible description. We manually corrected the entries every day, so befor the backup, all inChanger-Flags are set to 1 and all slots have the correct value. While i can not reproduze this failure by hand, i can not give you an actual listing. Sorry. Befor the job, at volume 122 the inchanger-flag was set to 1 and slot was set to 22. Befor the job, at volume 221 the inchanger-flag was set to 1 and slot was set to 22. The attachement "list volumes.txt" was made while the backup and the migration job were running. The "list volumes 2.txt" was made after completion of the jobs, so anything should have looked correct but doesn't. Stats were made while the jobs were running. Jobs completed sucessfuly, so there was no unusual output. The heap-size of the bacula-dir is always so large: dss-bacula-dir Version: 2.4.2 (26 July 2008) x86_64-pc-linux-gnu debian 4.0 Daemon started 07-Aug-08 15:42, 685 Jobs run since started. Heap: heap=5,005,312 smbytes=999,336 max_bytes=2,311,814 bufs=3,129 max_bufs=5,436 ---------------------------------------------------------------------- kern - 08-25-08 14:25 ---------------------------------------------------------------------- Could you attach a listing of two or three volumes that lost their InChanger flag using: llist volume=xxx Note it is "llist" rather than just "list". Also, please attach the output from the following bconsole commands: sql select * from Storage; quit This may help me track down what is causing the problem. I think it may be related to an "update slots" command or some similar command. In fact, if you recently did any "update" command, please see if you can remember what it was you did as this may help me track down the problem. ---------------------------------------------------------------------- slehmann - 08-25-08 16:01 ---------------------------------------------------------------------- I have added "list_volumes.txt" (timestamp 08-25-08) again with the following informations: * llist of volumes who lost the inchanger-flag * llist of volumes currently used by one job * log of job, you can see that the volumes are full and the next volume is beeing used * select * from storage * output from .storage. I don't know why select * from storage results tree storages. At the moment I have configured only two, but "FileChanger" was the original configured storage. Storage { # virtual file-changer Name = File Address = dss-bacula SD Port = 9103 Password = "secret" Device = FileAutoChanger Media Type = File Maximum Concurrent Jobs = 20 Autochanger = yes } # externes Bandlaufwerk Storage { Name = SL500-1 Address = dss-bacula SD Port = 9103 Password = "secret" Device = SL500-1 Media Type = LTO-3 Autochanger = yes Maximum Concurrent Jobs = 10 } #Storage { # Name = FileChanger # Address = dss-bacula # SD Port = 9103 # Password = "vbuwQO3OwYk7/6g4q5WKDbH/MGnGhAy4z9QW7WkZdUIn" # Device = FileAutoChanger # Media Type = File # Maximum Concurrent Jobs = 20 # Autochanger = yes #} Issue History Date Modified Username Field Change ====================================================================== 07-25-08 09:17 slehmann New Issue 07-26-08 07:05 kern Note Added: 0003503 07-26-08 07:05 kern Status new => feedback 07-29-08 07:18 slehmann Note Added: 0003510 08-04-08 14:09 slehmann File Added: list volumes.txt 08-04-08 14:09 slehmann File Added: stat dir.txt 08-04-08 14:09 slehmann File Added: Stat sd.txt 08-04-08 14:17 slehmann Note Added: 0003519 08-04-08 16:27 slehmann Note Added: 0003520 08-04-08 16:27 slehmann File Added: list volumes 2.txt 08-05-08 19:25 slehmann Note Edited: 0003519 08-05-08 19:52 kern Note Added: 0003522 08-08-08 12:12 slehmann Note Added: 0003529 08-11-08 09:34 slehmann Note Edited: 0003529 08-25-08 14:25 kern Note Added: 0003583 08-25-08 15:54 slehmann File Added: llist_volumes.txt 08-25-08 16:01 slehmann Note Added: 0003585 ====================================================================== |