On Fri, Mar 6, 2009 at 2:00 PM, Arno Lehmann <a...@its-lehmann.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 <a...@its-lehmann.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
