[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bacula-devel] Remaining dual changer problems
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:
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.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.