Hello, On Saturday 24 May 2008 15:08:19 Kern Sibbald wrote: > Hello Eric, > > I assume that since I haven't heard anything from you that the last fixes > (2.2.10-b4) to the reservation system, fixed the problems you were having. > For others on the list, the company Eric works for runs 270 nightly jobs so > they have a tendency to run into Bacula SD bugs.
Yes everything is ok right now. > There still remains one outstanding problem of which I am aware that > fortunately is not hitting you, and that is bug #1083 "SD attempts to load > volume already loaded in another drive for multi-drive disk autochanger". > This bug shows up only during swapping of a volume from one drive to > another and typically is created when PreferMountedVolumes=no. > > I know what is causing the problem and after thinking about different > solutions, I think the best one is to add a new autochanger script query. > For memory the current commands are: > > # The commands are: > # Command Function > # unload unload a given slot > # load load a given slot > # loaded which slot is loaded? > # list list Volume names (requires barcode reader) > # slots how many slots total? > # > > The new one would be "where" and would be called > > mtx-changer "changer-device" where "slot-number" > > the other two arguments would be ignored. This new function asks where a > Volume with "slot-number" is located. > > The answer can be: > > slot nnn > > or > > drive nnn If you ask "where 10" you will have slot 10 or drive 1 ok, or we can change the "load" function to do the work. load drive0 slot1 - check if slot1 is already loaded (do nothing if already in drive0) - load the slot1 to drive0 if slot1 is unloaded - exit with error code 1,2 or 3 and with a message "already loaded 2" And we have to handle the third case in the SD. > This command would be issued before each load request, and if the Volume is > already in the correct drive, nothing more would be done; if the volume is > in its slot, it would be loaded; and if the volume is in a different drive, > it would be unloaded, then loaded into the desired drive. > > This would allow a simple interface for the SD to ensure that it takes the > right action to load a particular slot in a particular drive without the > need for trying to track it within the SD. For me it makes the most sense > because it is the changer device that definitively knows where the volume > is. It makes sens and will simplify the code, it's just a bit strange to loose volume location across the code, but i know that it's a very complex part of the SD. > Aside from wanting feedback on this idea, the big question is when to > implement this. Clearly it should be done before the next major version as > it will allow us to eliminate a class of annoying little problems. > > I am also considering the possibility of implementing it in Branch-2.2, but > I really don't like that idea too much because it means that it will break > all the autochanger scripts implemented by users (at least one virtual disk > changer and the FreeBSD chio based script). In any case, it is *very* > unlikely to be implemented before the 2.2.10 release. I'm agree with you, changing the mtx script during a 2.2.X release is not a very good idea, but if the changelog and the error message is clear, i think that it can be done. Bye ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
