> > I am not sure if this functionality has changed from 1.38.X (as I use > > the drives directly now) > Multiple drive autochanger support has changed enormously since version 1.38.
Thank You. I am very sorry to assume that it was the same. I will update my configs as soon as I can. > > To minimize tape swapping, > > This is not currently possible due to current architecture constraints. I think what you described above was what I was looking for, I mean if bacula finds a tape in drive2 at the start of a new job there is no good reason to move it to drive1 and run the job there instead. One other feature I would like to see is if there are any empty drives when starting a job and none of the correct pools are loaded choose the empty drive instead of any unloading media. > > > maximize the use of the drives > > The above is not well defined. > I meant to not block on a second job from a different pool when there was a job running on the first and there is a free drive. You explained that this should not happen. > > and to prefer to use tapes with the Append status over grabbing a new tape. > This was again a result of me seeing more than one tape from a pool in my list media with the Append status. > I think what you and others have been seeing is problems associated with the > evolution of Bacula. There have been a whole series of "problems" to be > resolved that are particularly complicated when you are dealing with > multi-threaded programs, pruning/purging/recyling algorithms, and multiple > drive autochangers. It is extremely complicated and difficult to debug, and > rather than sitting down and developing it in one shot requiring two years, I > have implemented it in little steps, each time Bacula has gotten smarter. > Being that I am a software developer I understand how complex this type of problem is. And then when you factor in the different hardware and different operating systems the problem becomes much harder especially when the developer does not have these systems to test. I am very sorry for complaining about 1.38 problems I experienced assuming that they are still 2.X problems. My intent on entering this thread was to actually tone down the idea that the multidrive autochager code was buggy but that in my opinion with the experience that I had with bacula was the reported ill behavior was more a cause of complexity and the interaction of different configuration settings and several different scheduling rules that were probably not designed specifically for multidrive autochangers. Thanks, John ------------------------------------------------------------------------- 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
