Hello,
On 04.10.2005 09:42, Kern Sibbald wrote:
On Monday 03 October 2005 23:52, Arno Lehmann wrote:
...
The "right" solution would be that bacula before unloading a tape always
verifies that the slot it has in the catalog is actually free and passes
that slot as an argument to mtx-changer.
In other words - code changes.
Uh, I am confused here. Doesn't the mtx-changer script *always* specify both
a slot and a drive on the unload request when calling mtx?
The key to get rid of your confusion is *verifies that the slot it has
in the catalog is actually free* I think...
If somone has transferred a tape into a slot that Bacula has loading, that
will undoubtedly cause confusion, but otherwise, it seems to me most likely
to be an autoloader problem. This could be determined by turning on a little
debug code in the mtx-changer script.
Most certainly. The problem in this case might be to reproduce the
situation - as far as I understood Tom, he didn't change the tape
inventory, but the autochanger somehow lost track of the slots used. I
heard that before, and, although seldom, some autochangers seem to
forget their inventory from time to time. Manually moving tapes is a
good way for testing the robustness of bacula / mtx-changer, though :-)
Arno
--
IT-Service Lehmann [EMAIL PROTECTED]
Arno Lehmann http://www.its-lehmann.de
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
