Re: [Bacula-users] mtx-changer loaded issues

On Fri, Mar 6, 2009 at 2:00 PM, Arno Lehmann <al AT its-lehmann DOT de> wrote:
> Hi,
>
> 06.03.2009 16:20, (private) HKS wrote:
>> Thanks for the response.
>>
>> On Fri, Mar 6, 2009 at 3:12 AM, Arno Lehmann <al AT its-lehmann DOT de> 
>> wrote:
>>> Hi,
>>>
>>> 05.03.2009 21:57, (private) HKS wrote:
>>>> 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.
>>>
>>>> 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.
>
>>
>>>> <...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
>>>> the voltag indicates the slot that's loaded (whatever that means):
>>> Obviously the output format is different to what mtx-changer expects.
>>>
>>>> ----
>>>>
>>>> # ./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.
>
> Well, the above was nonsense as seen in the below output.
>
>> 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.
>
> 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.
>
>> 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,
>
> 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.
>
>> 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).
>
>> 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.
>
>> 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.
>
>> 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

------------------------------------------------------------------------------
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
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users