Le vendredi 23 octobre 2009 13:08:03, Spiros Ioannou a écrit :
> Hello dear developers,
> We recently bought a Quantum Scalar50 with 76 slots and 2 LTO-4 drivs.
> These are two Scalar50 units connected together, drives go to the bottom
> unit and the other unit serves as extra slots. mtx is 1.3.12, OS is CentOS
> At first, mtx-changer (bacula 3.0.1) didn't recognize most of the slots
> because 72 of them are marked as IMPORT/EXPORT except for the first 4.
The mtx-script can/should be adapted to your configuration and your hardware.
By default, we are not sure that IMPORT/EXPORT slots can be used like other
normal slots. Your situation tends to prove that we have the good approach.
If you can report the problem to your hardware vendor (yes, it looks like a
bug, so why not report it ?), perhaps they can correct this situation for the
next firmware revision.
It could also be a mtx bug, you can also report them the problem and see the
answer. Bacula will work better if sublayers are working as expected.
Workaround are always possible, but they require many hours of work for a
specific platform bug.
You can also try to install the latest mtx version to see if the output is the
> status: Data Transfer Element 0:Full (Unknown Storage Element
> Loaded):VolumeTag = ACW964L4 Data Transfer Element 1:Empty
> Storage Element 1:Empty
> Storage Element 2:Full :VolumeTag=ACW971L4
> Storage Element 3:Empty
> Storage Element 4:Empty
> Storage Element 5 IMPORT/EXPORT:Empty
> Storage Element 6 IMPORT/EXPORT:Full :VolumeTag=ACW970L4
> Storage Element 74 IMPORT/EXPORT:Full :VolumeTag=ACW974L4
> Storage Element 75 IMPORT/EXPORT:Full :VolumeTag=ACW973L4
> Storage Element 76 IMPORT/EXPORT:Full :VolumeTag=ACW972L4
> After changing the mtx-changer script to ignore the IMPORT/EXPORT I
> realized that the robot doesn't keep correct track of the loaded slot: 1)
> If the slot gets loaded to a drive directly from an IMPORT/EXPORT (I/E)
> slot (i.e. slot >4) then it is reported as coming from a random free
> non-I/E slot (1-4) if an empty I/E slot is found. For example if slot 3 is
> empty and a load element 70 to drive it gets reported as coming from slot
> 3. So when you unload it (with mtx) it goes back to 3 and not to 70. 2) If
> all non-I/E slots 1-4 were full when loading a tape from an I/E slot it is
> reported as "Unknown storage element" like in the example above, breaking
> the "loaded?" command
What you can do is to use the Import/Export area as "Import/Export" area only,
and if you have empty slots, just fill them.
> Issuing "label barcodes" fails because bacula thinks drive0 with the
> "unknown" element is empty because of the bad parsing. I fear that if i
> modify mtx-changer any further to trick it in seeing the unknown element
> as a random "empty" slot number, something will break in bacula.
It's also possible to tweak the mtx-changer script to retrieve the slot number
from the director.
From a Bacula point of view, maybe we can update the slot information after an
unload command, or choosing between the catalog and the mtx-changer output to
select the slot.
> Is there a way to make bacula keep track of tapes using just the barcode
> labels and ignore slots?
What we will do with Autochangers that don't have barcodes? At this time, we
trust mtx-changer information, if they are wrong, everything become harder.
> I presume this is what happens with commercial
Many *commercial* software doesn't support tapes or autochangers, others can't
update the content if a job is running, others have the same bug (if they
trust the autochanger firmware), we don't try to copy them.
> Any more thoughts?
> thank you,
> Spiros Ioannou
> Electrical Engineer
> IT Manager
> Hellenic National Audiovisual Archive