Kern Sibbald wrote: > On Sunday 20 May 2007 20:33, Andreas Helmcke wrote: >> Kern Sibbald wrote: >>> Unless I am mistaken, this sounds like a standard support problem rather >>> than >>> something specific with Beta version 2.1.10, and as such, you should report >>> this on the bacula-users list where you are more likely to get a response. >> >> The reason, why i do think that it is a 2.1.10 specific problem is, that with >> version 2.0.3 in the same configuration bacula always finds an appendable >> volume for each job and does change the tapes accordingly. >> *This* error only happens with version 2.1.10. >> >> In version 2.0.3 bacula sometimes changes tapes to often, as i already >> reported to the bacula-users list. > > Well, it would have been helpful if you mentioned these points in the > beginning. > > From everything I see, this is most likely not a bug, and if it is a bug, it > is probably one that is in 2.0.3 as well. (please note: I said "most likely > not" and "probably"). > > It appears to me that the volume that job 3 wanted was perhaps not purged at > the time that job 3 started, because when you finally got it to work, the > first thing the SD did was recycle the volume. Since there is no indication > when the volume was purged or marked purged, I can only assume it was after > job 3 had started, and instead of cancelling it, you probably could have > simply done a "mount" and it would have accomplished the same thing. >
I think you are right; a simple mount would have done the trick also; but there have been other appendable and purged volumes in this pool, which could have been used. Ok, Ok, I see; i have to elaborate more on this topic. For my experience searching for a bug is sometimes like hunting a very shy, unknown animal which, in the beginning of your hunt, you even don't know if it exists. All you have got is a couple of more or less reliable eyewitnesses: - Some have seen something, which was not there (RTFM). - Some have seen something, but misinterpreted their sightings (configuration or hardware errors). - Some claim to have seen an alien (I think, you know them :-) ). - Some might have seen our animal. - And even more didn't report their sightings, because they where afraid that they where fooled by their vision and don't wont to be mixed up with this folk seeing unreal phenomenons. So let me try to summarize some of the reported sightings which *might* lead to our target: 1. me; to bacula-users; yesterday: reporting that bacula 2.1.10 doesn't find an appendable volume, even if there was one in the pool. 2. me; to bacula.users; on 19th May: reporting that bacula 2.0.3 keeps switching tapes even if an appendable volume is already loaded into one drive. 3. Adam Cécile; to bacula-users; on 18th May: reporting that his bacula (V 1.38) wanted to mount a volume, which is not accessible (not in changer) while there where plenty of usable volumes in changer. 4. Alan Brown; to bacula-users; today, answering to 2. reporting that bacula 2.0.3 "occasionally mounts and appends to a second tape when lots of jobs are running." 5. Jeff Kalichik; to bacula-users; on 8th April: reporting that V2.0.2 preferred to get a purged volume, which is not in the changer, rather than using a volume which is usable and *in* changer thus blocking the backup. 6. me; to bacula-users; on 14th Feb: My first report that bacula (this time Version 2.something) is doing something fishy while selecting a volume for a job when using an autochanger with multiple drives. 6.a and 6.b: answers from Alan Brown (V ???) and John Drescher (V1.38) confirming similar problems for their setup. Not to mention more odd decisions of bacula which tape to use next which I did not report or analyze more deeply because of some other (hardware / configuration) problems which I had to solve first which might or might not have implications on the volume selection schema. So to summarize my impressions: There *might* be a bug in the volume-selection-code of bacula which exists at least from V1.38 up to V2.1.10beta which leads sometimes to selecting the wrong volume for a job. As far as I can tell (but my vision might be clouded by the circumstance, that I am using a multidrive autochanger myself) is, that this bug shows his head more often (or only) when using a (multidrive) autochanger. By now there are far, far to many if's, might's, and more subjunctives to file a bug report. Even worse: while I tried to track down our shy animal (reproduce the bug) i started manually the jobs which normally lead to the reported errors and (you guessed what happened?): Everything worked like a charm. The correct (already loaded) volumes where chosen for each job. Nothing to complain about. Maybe there is no bug and all the reported problems are completely unrelated and have there causes in different configuration and / or hardware errors. But: as long as there is the slightest chance that this beast of a bug _really_ exists, I'll keep on hunting :-). Andreas P.S.: If some reader has any idea how to set up a trap to catch this beast (bug) please step forward and speak. I am willing to try everything (or, almost everything, because I only have one backup device (autochanger) and I do need a reliable backup ;-) ) ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
