Doug> Might this also support the ability to have multiple changers Doug> active at the same time?
Dustin> This particular patch does not address this issue - but it's a Dustin> good issue! Dustin> It's not clear exactly how we'd model this. One model is to Dustin> assign each scribe to its own changer, with the result that Dustin> one scribe may run out of tapes while another has a whole Dustin> library full of inactive media. Another model is to create an Dustin> "aggregate changer" from which all of the scribes operate -- Dustin> basically emulating one large changer that is the combination Dustin> of all of the real changers. This, of course, introduces Dustin> complexities in that a tape in one changer can't be loaded Dustin> into a drive in another changer. Hmm, I guess it depends on if the changers are similar in number of tapes, capacity of the tapes, number of tape drives, and speed of the tape drives. If your changers are all similar, as our are, then it seems that treating all of the tapes in all of the changers as a single pool makes sense. That over a dumpcycle things should for the most part average out. When you start out you need to have similar numbers of open media in each changer. I would think that avoiding the problem where a scribe needs a tape moved from one changer to antoher is the right approach. I'd really hate to have to shuffle tapes between changers on a daily basis. I guess that the worst case of assigning a scribe to a specific changer is that antoher scribe may run out of tapes for a particular run and your tape throughput is reduced since only one changer has eligible tapes. But I really think that with a bit of forethought as to how you balance the tapes in the changers, and also the averaging you would get over multiple runs that things would settle out. In our case we have three 30 tape AIT changers each with 2 drives for a total of 90 total slots and 6 tape drives. All of our changers and tape drives are the same. I'll admit I'm a bit unsure how Amanda breaks ties when multiple eligible tapes have the same date. Is it by the order in the tapelist file, or something else? This perhaps makes a difference especially if Amanda always starts writing to the first eligible tape in the first changer. This could cause the tapes in that changer to be used more frequently, but then the other changers would take up the slack. You may end up with a situation where you've lost performance because not all tape drives can be fed tapes. I'll admit I'm selfishly trying to not have to balance multiple Amanda configs and also not have to change tapes. I'm just lazy.
