On Wednesday 23 May 2007 17:00, John Drescher wrote: > > With perfer mounted volumes on (default), as you know the algorithm will > > always select a drive that is currently mounted, however, if I am not > > mistaken, when no jobs are running and there are two drives with appropriate > > Volumes mounted, it will attempt to alternate between them, and if there are > > multiple drives actually writing, the algorithm will attempt to balance the > > number of jobs on each drive (I didn't look at the code, and this last remark > > may only apply if prefer mounted volumes is off). > > > 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. > but what I saw was that with prefer mounted > volumes on bacula would most of the time use the first drive when I > selected the autochanger resource. I think that is typically what happens, if for no other reason than the drive is very likely to have a Volume already in it, and the current algorithm always selects the first drive that is available. > If a job was running, a second job > to a second pool would sometimes block instead of running on the > unused tape drive. I've never seen that happen. What did happen from time to time was that the SD would become confused about what Volumes were actually mounted. This was particularly a problem in 1.38.x, a bit less in 2.0.x and should now be resolved (barring any bugs) in 2.1.x > If no job was running, a job to a different pool > than the tape in the first drive would cause the tape to be unloaded > from the first drive and sometimes the tape needed was already in the > second drive so it too was unloaded to put it into the first drive. If the correct tape is already in a drive before the job starts, Bacula will always select that particular drive. However, once Bacula decides to use a particular drive, it will use that drive for the whole job. Thus, if later in a job, it needs a tape that is on another drive, it will move the tape. This is still the case. > > > > If you have prefer mounted volumes off bacula will pick any tape in the pool > > > when running jobs. > > > > The algorithm for picking available Volumes from the correct Pool is in the > > Director, and is totally independent of the state of prefer mounted volumes > > and anything else that is going on in the SD ... > > > Sorry. My problem here is from time to time I have seen that bacula > has 2 or more tapes with the Append status for a single pool which I > find a little annoying. Unless you specifically created several tapes in the same pool (they are created with Append status), there is no reason for Bacula to have more than one tape with Append status. I have never seen this. Even if this is the case, it shouldn't make any difference since Bacula will only normally write on a single tape unless you tell it to do otherwise, and it will *always* select the same tape *every* time providing that the tape is in the autochanger and marked as such. The biggest problem people have is that they move tapes in and out of the magazine and they do not follow the proceedure in the manual. > A way to avoid this I guess is not to have any > unused labeled tapes in a pool and let bacula grab new tapes from > either recycling or the scratch pool. There is no real need to avoid this, but as I say above, unless there is an "operator" error, it is not a condition that Bacula will create itself. > > > > I would say that both results are not what a user of a multitape changer > > would want. > > > > Well that is an interesting remark. What does a user of a multiple "drive" > > autochanger want? > > > To minimize tape swapping, This is not currently possible due to current architecture constraints. > maximize the use of the drives The above is not well defined. > and to prefer to use tapes with the Append status over grabbing a new tape. This is and has always been the case unless you either don't properly inform Bacula what is in the autochanger or you modify what is in the autochanger. One prior problem that people had is that a tape would be pruned, but not marked purged, and thus not recyceable. This could be considered a bug but was actually a design fault. It was caused because the code would prune but didn't do the exhaustive checks that are necessary to detect that everything has been pruned from the Volume so that it could be marked Purged. As such, users sometimes had to unmount and remount the drive to force Bacula to rescan Volumes and notice that they were fully pruned. This was a real problem, and is now fixed in 2.1.x (barring any bugs). > > One thing that might be different between my needs and others is that > I never want to use more than one drive at a time for a single pool. I > am not sure that made sense so I will try to say it a different way... > I mean that if there are concurrent jobs running for a single pool I > want this to only be on a single drive at a time. This is the default action. 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. Once the bugs are out of 2.1.x we will be 95% to where we want to go -- the remaining problem is to teach Bacula how to switch drives in the middle of a job. The biggest problem I have is that users ususally say "it doesn't work" or they cite three different problems at the same time, and I am totally unable to reproduce it, so there is virtually no way to fix it. In fact, most users are unable to reproduce it. If you can't reproduce it how can I fix it. Recently Eric ran into a problem where the SD got confused about what tape was on what drive -- it wanted the same tape on 2 drives. Well, I couldn't reproduce it, but he figured out how to reproduce it, and with him rapidly testing my new versions (many times!), I was finally able to resolve that problem. ------------------------------------------------------------------------- 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
