On 08/12/15 16:40, Heitor Faria wrote:
>> I'll look into their usage further, in the meantime it would be nice
>> if bacula wouldn't lock up for days using the "acquire" dance ;)
You have to know why it's locked that way and that means turning up the
debug levels/looking at logs.
> Sorry Uwe: now I fully comprehend the situation.
> Did you try to enable mtx-changer logging / debugging that can be turned on
> at mtx-changer.conf file?
I've added this to the start of mtx-changer in order to improve
reliability (it's based on the segment which checks to see if a drive is
ready).
Most changers will throw errors if you try to talk to them with the
magazine slot or doors open and whilst catalogging changes.
MTX=/usr/sbin/mtx
=====
TAPEINFO=/sbin/tapeinfo
# Wait for changer to be ready
# wait up to 300 seconds
i=0
while [ $i -le 300 ]; do # Wait max 300 seconds
if /usr/sbin/tapeinfo -f $1 2>&1 | grep "Ready: yes" >/dev/null
2>&1; then
break
fi
debug $dbglvl "Device $1 - not ready, retrying..."
sleep 1
i=`expr $i + 1`
done
#
=====
It would be good to see this rolled into the upstream version as this
stopped a number of errors that Baclula would get upset about.
I have another kludge further into the script which specifically checks
to see if a tape device is being seen twice or more (it will in
multipathed environments such as FC or Dualport SAS) and unlocks BOTH
instances.
Scsi tape drives will accept a "door lock" command from any source but
locks are independent (ie, lock commands from 2 sources are treated as 2
separate locks, not one lock) and each unlock must come from the _same_
WWID as the lock command (each scsi/FC controller is a different WWID).
There's no way of overriding this other than power cycling the drive.
Prior to this kludge, disturbances in the Fibre fabric would sometimes
lead to udev changing /dev/tape/by-id/nst-WWID switching from /dev/nstN
to /dev/nstZ and if any tapes were loaded bacula could no longer unload
them.
I also wrote scripts to transfer tapes from the library internals to the
mailslots or vice versa. This is specifically to avoid operator errors
such as dropping a tape in a slot that looks empty because the tape
that's supposed to be in it is actually in a drive, etc, or removing a
tape that's marked as Append.
Considering the usefulness of barcodes, you'd be nuts to buy a library
which can't read them. Not having them makes things much more manually
intensive or requires significant extra scripting/slowness to workaround
(bear in mind that tapes have limited lifespans, so loading them into
drives just to read labels is wasteful)
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
