[Bacula-devel] Remaining dual changer problems

[Kern S. <ke...@si...>]

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.

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

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.

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.

Comments?

Best regards,

Kern