[Bacula-users] mtx-changer loaded issues

Hi,

Post by (private) HKS
Hello,
I'm introducing a Dell Powervault 124T autochanger to my Bacula
config, and am having a bit of trouble with the mtx-changer script.
Bacula 2.2.8 on OpenBSD 4.4.

Hmm... OpenBSD is not something I'm very familiar with. IIRC, the tape
and autochanger interfaces behave a bit differently than what you see
under linux and solaris.

Post by (private) HKS
The problem is that "mtx-changer /dev/ch0 loaded 0 /dev/nrst0 0" does
not work as expected. Here's a quick cut/paste that shows what I mean.
----
# chio status -v

Yup... you see, mtx-changer is supposed to use a generic SCSI
interface - /dev/sgX under linux - and it might be possible that the
/dev/chX interface works differently (under solaris this does not seem
to be an issue, by the way).

There's a changer control script suitable for chio somewhere in the
Bacula distribution - you might try that.

Post by (private) HKS
<...snip...>
drive 0: <ACCESS,FULL> voltag: <000015L3:0>
# ./mtx-changer /dev/ch0 loaded 0 /dev/nrst0 0
# btape -c /etc/bacula/bacula-sd.conf 124T-Drive
Tape block granularity is 1024 bytes.
btape: butil.c:285 Using device: "124T-Drive" for writing.
05-Mar 15:49 btape JobId 0: 3301 Issuing autochanger "loaded? drive 0" command.
05-Mar 15:49 btape JobId 0: 3302 Autochanger "loaded? drive 0",
result: nothing loaded.
----
The key seems to be that mtx-changer loaded is expecting a different
format than my system is returning. I modified mtx-changer so I'm now
getting the voltag when I check what's loaded, but now btape believes

Obviously the output format is different to what mtx-changer expects.

Post by (private) HKS
----
# ./mtx-changer /dev/ch0 loaded 0 /dev/nrst0 0
000015L3
# btape -c /etc/bacula/bacula-sd.conf 124T-Drive
Tape block granularity is 1024 bytes.
btape: butil.c:285 Using device: "124T-Drive" for writing.
05-Mar 15:52 btape JobId 0: 3301 Issuing autochanger "loaded? drive 0" command.
05-Mar 15:52 btape JobId 0: 3302 Autochanger "loaded? drive 0", result
is Slot 15.
----
This causes issues because Bacula tries to unload the tape into slot
15, which is not the right slot. Also, my barcodes go higher, so
there's going to be some weirdness when it tries to do this with a
barcode number greater than the number of slots.
What exactly is Bacula expecting from the mtx-changer loaded command?
Is it supposed to be just a true-false value, an empty slot number,
what?

The slot number where the tape came from (and which should be empty,
but that's not verified).

In your above output "voltag: <000015L3:0>" , guess the 0 behind the
colon is the slot. If that's the case, fixing mtx-changer to return
that number would not be too hard.

I don't have access to an OpenBSD box or some sample outputs from chio
/ mtx there, but I believe modifying mtx-changer to correctly use the
output generated there should be easy enough - if you know a bit about
awk or sed.

Arno

Post by (private) HKS
Thanks for the help.
-HKS
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de

(private) HKS

2009-03-06 15:20:28 UTC

Thanks for the response.

Post by (private) HKS
Hello,
I'm introducing a Dell Powervault 124T autochanger to my Bacula
config, and am having a bit of trouble with the mtx-changer script.
Bacula 2.2.8 on OpenBSD 4.4.

Hmm... OpenBSD is not something I'm very familiar with. IIRC, the tape
and autochanger interfaces behave a bit differently than what you see
under linux and solaris.

Post by (private) HKS
The problem is that "mtx-changer /dev/ch0 loaded 0 /dev/nrst0 0" does
not work as expected. Here's a quick cut/paste that shows what I mean.
----
# chio status -v

Yup... you see, mtx-changer is supposed to use a generic SCSI
interface - /dev/sgX under linux - and it might be possible that the
/dev/chX interface works differently (under solaris this does not seem
to be an issue, by the way).
There's a changer control script suitable for chio somewhere in the
Bacula distribution - you might try that.

The OpenBSD port of Bacula has mtx-changer already modified to work
with chio, but it's incomplete. Or, perhaps, my 124T doesn't respond
like most.

Obviously the output format is different to what mtx-changer expects.

The slot number where the tape came from (and which should be empty,
but that's not verified).
In your above output "voltag: <000015L3:0>" , guess the 0 behind the
colon is the slot. If that's the case, fixing mtx-changer to return
that number would not be too hard.
I don't have access to an OpenBSD box or some sample outputs from chio
/ mtx there, but I believe modifying mtx-changer to correctly use the
output generated there should be easy enough - if you know a bit about
awk or sed.
Arno

Ugh, so there's an expectation that the tape in the drive still be
associated with the slot it came from. Unfortunately, that isn't done
by the OS. Here's the full output of chio status -v:
----
# chio status -v
picker 0: voltag: <:0>
slot 0: <ACCESS> voltag: <:0>
slot 1: <ACCESS> voltag: <:0>
slot 2: <ACCESS> voltag: <:0>
slot 3: <ACCESS> voltag: <:0>
slot 4: <ACCESS,FULL> voltag: <000013L3:0>
slot 5: <ACCESS,FULL> voltag: <000012L3:0>
slot 6: <ACCESS> voltag: <:0>
slot 7: <ACCESS,FULL> voltag: <000011L3:0>
slot 8: <ACCESS> voltag: <:0>
slot 9: <ACCESS> voltag: <:0>
slot 10: <ACCESS> voltag: <:0>
slot 11: <ACCESS> voltag: <:0>
slot 12: <ACCESS> voltag: <:0>
slot 13: <ACCESS> voltag: <:0>
slot 14: <ACCESS,FULL> voltag: <000015L3:0>
slot 15: <ACCESS> voltag: <:0>
drive 0: <ACCESS,FULL> voltag: <000014L3:0>
----

I made some simple modifications to the mtx-changer script that sets
it to associate the tape with the first empty slot on the changer, but
that leads me to some followup questions. I may be misunderstanding
the manual, but I couldn't quite figure these out from the
documentation.

1 - Even though this drive and these tapes are barcode enabled (hence
the voltag), does Bacula operate on them by slot?
2 - I have four sets of five tapes each for offsite backups. All are
barcode labeled (used to be on a Backup Exec system). Will Bacula
expect that the same tapes are in the same slots each time?
3 - Does ALL of Bacula's interaction with the autochanger take place
via mtx-changer?

Thanks again for the help.

-HKS

--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

Arno Lehmann

2009-03-06 19:00:39 UTC

Hi,

Post by (private) HKS
Thanks for the response.

Post by (private) HKS
Hello,
I'm introducing a Dell Powervault 124T autochanger to my Bacula
config, and am having a bit of trouble with the mtx-changer script.
Bacula 2.2.8 on OpenBSD 4.4.

Hmm... OpenBSD is not something I'm very familiar with. IIRC, the tape
and autochanger interfaces behave a bit differently than what you see
under linux and solaris.

Post by (private) HKS
The problem is that "mtx-changer /dev/ch0 loaded 0 /dev/nrst0 0" does
not work as expected. Here's a quick cut/paste that shows what I mean.
----
# chio status -v

Yup... you see, mtx-changer is supposed to use a generic SCSI
interface - /dev/sgX under linux - and it might be possible that the
/dev/chX interface works differently (under solaris this does not seem
to be an issue, by the way).
There's a changer control script suitable for chio somewhere in the
Bacula distribution - you might try that.

The OpenBSD port of Bacula has mtx-changer already modified to work
with chio, but it's incomplete. Or, perhaps, my 124T doesn't respond
like most.

Ok, so I'll assume that mtx itself works, and does work as under linux
/ solaris.

Post by (private) HKS

Obviously the output format is different to what mtx-changer expects.

The slot number where the tape came from (and which should be empty,
but that's not verified).
In your above output "voltag: <000015L3:0>" , guess the 0 behind the
colon is the slot.

Well, the above was nonsense as seen in the below output.

Post by (private) HKS
If that's the case, fixing mtx-changer to return

Post by Arno Lehmann
that number would not be too hard.
I don't have access to an OpenBSD box or some sample outputs from chio
/ mtx there, but I believe modifying mtx-changer to correctly use the
output generated there should be easy enough - if you know a bit about
awk or sed.
Arno

Ugh, so there's an expectation that the tape in the drive still be
associated with the slot it came from. Unfortunately, that isn't done
by the OS.

Not actually very bad, because Bacula explicitly unloads volumes to
the slot they came from. You just need to make sure that slot isn't
used by any other tape in between, but as long as you're nly using
Bacula with the changer that's not a problem.

Post by (private) HKS
----
# chio status -v
picker 0: voltag: <:0>
slot 0: <ACCESS> voltag: <:0>
slot 1: <ACCESS> voltag: <:0>
slot 2: <ACCESS> voltag: <:0>
slot 3: <ACCESS> voltag: <:0>
slot 4: <ACCESS,FULL> voltag: <000013L3:0>
slot 5: <ACCESS,FULL> voltag: <000012L3:0>
slot 6: <ACCESS> voltag: <:0>
slot 7: <ACCESS,FULL> voltag: <000011L3:0>
slot 8: <ACCESS> voltag: <:0>
slot 9: <ACCESS> voltag: <:0>
slot 10: <ACCESS> voltag: <:0>
slot 11: <ACCESS> voltag: <:0>
slot 12: <ACCESS> voltag: <:0>
slot 13: <ACCESS> voltag: <:0>
slot 14: <ACCESS,FULL> voltag: <000015L3:0>
slot 15: <ACCESS> voltag: <:0>
drive 0: <ACCESS,FULL> voltag: <000014L3:0>
----
I made some simple modifications to the mtx-changer script that sets
it to associate the tape with the first empty slot on the changer,

That's not a good thing. You should leave that decision to Bacula when
unloading, and just need to make sure that Bacula always has an
up-to-date catalog.

Post by (private) HKS
but
that leads me to some followup questions. I may be misunderstanding
the manual, but I couldn't quite figure these out from the
documentation.
1 - Even though this drive and these tapes are barcode enabled (hence
the voltag), does Bacula operate on them by slot?

Yes. Partly because Bacula can also handle autochangers and tapes
without barcode (capability).

Post by (private) HKS
2 - I have four sets of five tapes each for offsite backups. All are
barcode labeled (used to be on a Backup Exec system). Will Bacula
expect that the same tapes are in the same slots each time?

Mostly yes... the key thing to remember is to run 'update slots' after
you change tapes.

Post by (private) HKS
3 - Does ALL of Bacula's interaction with the autochanger take place
via mtx-changer?

Yes.
But Bacula keeps the slot assignement of any volume in the catalog, so
it expects the situation in reality to match its own ideas of where
tapes are.

Post by (private) HKS
Thanks again for the help.

I believe with the above clarifications most of your issues should be
resolvable... you'll probably need to undo or change your mtx-changer
modifications.

Arno

Post by (private) HKS
-HKS

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Bacula-users mailing list
https://lists.sourceforge.net/lists/listinfo/bacula-users

--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de

(private) HKS

2009-03-06 19:30:12 UTC

Post by (private) HKS
Thanks for the response.

Post by (private) HKS
Hello,
I'm introducing a Dell Powervault 124T autochanger to my Bacula
config, and am having a bit of trouble with the mtx-changer script.
Bacula 2.2.8 on OpenBSD 4.4.

Hmm... OpenBSD is not something I'm very familiar with. IIRC, the tape
and autochanger interfaces behave a bit differently than what you see
under linux and solaris.

Post by (private) HKS
The problem is that "mtx-changer /dev/ch0 loaded 0 /dev/nrst0 0" does
not work as expected. Here's a quick cut/paste that shows what I mean.
----
# chio status -v

Yup... you see, mtx-changer is supposed to use a generic SCSI
interface - /dev/sgX under linux - and it might be possible that the
/dev/chX interface works differently (under solaris this does not seem
to be an issue, by the way).
There's a changer control script suitable for chio somewhere in the
Bacula distribution - you might try that.

The OpenBSD port of Bacula has mtx-changer already modified to work
with chio, but it's incomplete. Or, perhaps, my 124T doesn't respond
like most.

Ok, so I'll assume that mtx itself works, and does work as under linux
/ solaris.

Post by (private) HKS

Obviously the output format is different to what mtx-changer expects.

The slot number where the tape came from (and which should be empty,
but that's not verified).
In your above output "voltag: <000015L3:0>" , guess the 0 behind the
colon is the slot.

Well, the above was nonsense as seen in the below output.

Post by (private) HKS
If that's the case, fixing mtx-changer to return

Ugh, so there's an expectation that the tape in the drive still be
associated with the slot it came from. Unfortunately, that isn't done
by the OS.

That's not a good thing. You should leave that decision to Bacula when
unloading, and just need to make sure that Bacula always has an
up-to-date catalog.

Yes. Partly because Bacula can also handle autochangers and tapes
without barcode (capability).

Mostly yes... the key thing to remember is to run 'update slots' after
you change tapes.

Post by (private) HKS
3 - Does ALL of Bacula's interaction with the autochanger take place
via mtx-changer?

Yes.
But Bacula keeps the slot assignement of any volume in the catalog, so
it expects the situation in reality to match its own ideas of where
tapes are.

Post by (private) HKS
Thanks again for the help.

I believe with the above clarifications most of your issues should be
resolvable... you'll probably need to undo or change your mtx-changer
modifications.
Arno

Okay, I think I understand how Bacula is handling these. I'm testing
some other modifications to the mtx-changer script, though. If anybody
has a working autochanger on Linux, could you send me the following
output for comparison's sake?

- mtx -f <device> inventory
- mtx -f <device> status
- mtx-changer <device> list
- mtx-changer <device> loaded 0 <drive> <drive index>

This would be really, really helpful.

-HKS

John Drescher

2009-03-06 19:49:29 UTC

Post by (private) HKS
Okay, I think I understand how Bacula is handling these. I'm testing
some other modifications to the mtx-changer script, though. If anybody
has a working autochanger on Linux, could you send me the following
output for comparison's sake?
- mtx -f <device> inventory
- mtx -f <device> status
- mtx-changer <device> list
- mtx-changer <device> loaded 0 <drive> <drive index>
This would be really, really helpful.

dev6 ~ # mtx -f /dev/autochanger1 inventory
dev6 ~ # mtx -f /dev/autochanger1 status
Storage Changer /dev/autochanger1:2 Drives, 24 Slots ( 1 Import/Export )
Data Transfer Element 0:Empty
Data Transfer Element 1:Full (Unknown Storage Element Loaded):VolumeTag = A00048
Storage Element 1:Full :VolumeTag=A00030
Storage Element 2:Full :VolumeTag=A00029
Storage Element 3:Full :VolumeTag=A00059
Storage Element 4:Full :VolumeTag=A00037
Storage Element 5:Full :VolumeTag=A00023
Storage Element 6:Full :VolumeTag=A00006
Storage Element 7:Full :VolumeTag=A00007
Storage Element 8:Full :VolumeTag=A00020
Storage Element 9:Full :VolumeTag=A00028
Storage Element 10:Full :VolumeTag=A00021
Storage Element 11:Full :VolumeTag=A00054
Storage Element 12:Full :VolumeTag=A00039
Storage Element 13:Empty:VolumeTag=
Storage Element 14:Full :VolumeTag=A00012
Storage Element 15:Full :VolumeTag=A00046
Storage Element 16:Full :VolumeTag=A00049
Storage Element 17:Full :VolumeTag=A00009
Storage Element 18:Full :VolumeTag=A00014
Storage Element 19:Full :VolumeTag=A00057
Storage Element 20:Full :VolumeTag=A00060
Storage Element 21:Full :VolumeTag=A00015
Storage Element 22:Full :VolumeTag=A00043
Storage Element 23:Full :VolumeTag=A00061
Storage Element 24 IMPORT/EXPORT:Empty:VolumeTag=
dev6 ~ #
dev6 ~ # mtx -f /dev/autochanger1 list
Usage:
mtx --version
mtx [ -f <loader-dev> ] noattach <more commands>
mtx [ -f <loader-dev> ] inquiry | inventory
mtx [ -f <loader-dev> ] [nobarcode] status
mtx [ -f <loader-dev> ] first [<drive#>]
mtx [ -f <loader-dev> ] last [<drive#>]
mtx [ -f <loader-dev> ] next [<drive#>]
mtx [ -f <loader-dev> ] previous [<drive#>]
mtx [ -f <loader-dev> ] [invert] load <storage-element-number> [<drive#>]
mtx [ -f <loader-dev> ] [invert] unload [<storage-element-number>][<drive#>]
mtx [ -f <loader-dev> ] [eepos eepos-number] transfer
<storage-element-number> <storage-element-number>
mtx [ -f <device> ] eject

Loaded is not a command either.

John

(private) HKS

2009-03-06 20:10:56 UTC

Post by John Drescher

dev6 ~ # mtx -f /dev/autochanger1 inventory
dev6 ~ # mtx -f /dev/autochanger1 status
Storage Changer /dev/autochanger1:2 Drives, 24 Slots ( 1 Import/Export )
Data Transfer Element 0:Empty
Data Transfer Element 1:Full (Unknown Storage Element Loaded):VolumeTag = A00048
Storage Element 1:Full :VolumeTag=A00030
Storage Element 2:Full :VolumeTag=A00029
Storage Element 3:Full :VolumeTag=A00059
Storage Element 4:Full :VolumeTag=A00037
Storage Element 5:Full :VolumeTag=A00023
Storage Element 6:Full :VolumeTag=A00006
Storage Element 7:Full :VolumeTag=A00007
Storage Element 8:Full :VolumeTag=A00020
Storage Element 9:Full :VolumeTag=A00028
Storage Element 10:Full :VolumeTag=A00021
Storage Element 11:Full :VolumeTag=A00054
Storage Element 12:Full :VolumeTag=A00039
Storage Element 13:Empty:VolumeTag=
Storage Element 14:Full :VolumeTag=A00012
Storage Element 15:Full :VolumeTag=A00046
Storage Element 16:Full :VolumeTag=A00049
Storage Element 17:Full :VolumeTag=A00009
Storage Element 18:Full :VolumeTag=A00014
Storage Element 19:Full :VolumeTag=A00057
Storage Element 20:Full :VolumeTag=A00060
Storage Element 21:Full :VolumeTag=A00015
Storage Element 22:Full :VolumeTag=A00043
Storage Element 23:Full :VolumeTag=A00061
Storage Element 24 IMPORT/EXPORT:Empty:VolumeTag=
dev6 ~ #
dev6 ~ # mtx -f /dev/autochanger1 list
mtx --version
mtx [ -f <loader-dev> ] noattach <more commands>
mtx [ -f <loader-dev> ] inquiry | inventory
mtx [ -f <loader-dev> ] [nobarcode] status
mtx [ -f <loader-dev> ] first [<drive#>]
mtx [ -f <loader-dev> ] last [<drive#>]
mtx [ -f <loader-dev> ] next [<drive#>]
mtx [ -f <loader-dev> ] previous [<drive#>]
mtx [ -f <loader-dev> ] [invert] load <storage-element-number> [<drive#>]
mtx [ -f <loader-dev> ] [invert] unload [<storage-element-number>][<drive#>]
mtx [ -f <loader-dev> ] [eepos eepos-number] transfer
<storage-element-number> <storage-element-number>
mtx [ -f <device> ] eject
Loaded is not a command either.
John

Thanks a lot, John. The list/loaded commands were actually to be
passed to mtx-changer so I can see how it is interpreting the output
coming from mtx itself.

-HKS

John Drescher

2009-03-06 20:22:32 UTC

Post by (private) HKS
Thanks a lot, John. The list/loaded commands were actually to be
passed to mtx-changer so I can see how it is interpreting the output
coming from mtx itself.

Sorry. I will get that..

dev6 bacula # ./mtx-changer /dev/autochanger1 list
1:A00030
2:A00029
3:A00059
4:A00037
5:A00023
6:A00006
7:A00007
8:A00020
9:A00028
10:A00021
11:A00054
12:A00039
14:A00012
15:A00046
16:A00049
17:A00009
18:A00014
19:A00057
20:A00060
21:A00015
22:A00043
23:A00061

dev6 bacula # ./mtx-changer /dev/autochanger1 loaded 0 0 23
dev6 bacula #

Hmm. I no output for the loaded command.

John

(private) HKS

2009-03-06 22:29:02 UTC