In the message dated: Mon, 02 Apr 2012 11:12:35 EDT,
The pithy ruminations from "Clark, Patricia A." on
<[Bacula-users] Best method for managing mtx "Data Transfer Element" numbers to
scsi tape> were:
=> I am new to Bacula and I am in the process of installing and configuring the
software. Somethin
=> g that is giving me some headaches is the mtx numbering on the drives vs the
/dev/st assignments
=> . The output of the mtx status on the auto changer and the the device
assignment is below:
=>
=>
=> Data Transfer Element 0:Empty <-- /dev/st5
=>
=> Data Transfer Element 1:Empty <-- /dev/st1
=>
=> Data Transfer Element 2:Empty <-- /dev/st0
=>
=> Data Transfer Element 3:Empty <-- /dev/st2
=>
=> Data Transfer Element 4:Empty <-- /dev/st3
=>
=> Data Transfer Element 5:Empty <-- /dev/st4
You almost certainly want to use the non-rewinding devices (/dev/nst*).
=>
=>
=> Ideally, I'd like the numbering to correspond, but I'm finding that would
take writing some udev
=> rules. I don't have any experience in doing that and most examples
reference writing for sd.
=> I know I assign the index number to the device in bacula-sd. So, should the
naming convention w
=> ork best to match the transfer element or the scsi tape number? I'v found
some references to th
=> e use of environment variables for the tape devices. I can see where this
would be helpful in s
=> cripts. What is the "rule of thumb" for addressing this issue?
The environment variable ($TAPE) is not very useful, as Bacula almost
certainly ignores it, as it can only be set to a single value at a time, and
as it would need to be redefined after any event that might change the
correspondence between the actual hardware devices and the device files in
/dev/[n]st*.
The number corresponding to each /dev/st* file is not fixed--it will
change on reboots or SCSI device rediscovery depending on the order in
which devices are found. The numbering will be different across multiple
servers on the same SAN.
The "rule of thumb" is to find some unique information about each hardware
device (fibre WWN, serial number, etc) and create a link between the
/dev/st* (or /dev/sg* for the mtx changer device) file and the symbolic
name you will use within Bacula.
So, bacula will be configured to use, for example, /dev/tape1, /dev/tape2,
/dev/changer1, etc., where those are each symbolic links to the /dev/st*
and /dev/sg* files.
Those symbolic links must be recreated on each reboot, and potentially due to
events like SCSI bus rescans or fibre LIP resets.
The easiest way under Linux to trigger checking and recreating those
links is via udev.
Let me provide a specific example.
We've got a fibre-attached tape library with two drives. The library has
dual fibre connections. With multipathing, this means that each server on the
SAN may see 2 changer devices and 4 drives (subject to SAN zoning).
Here are our /etc/udev/rules.d/55-bacula rules:
-------------------------------------
KERNEL=="sg*", SUBSYSTEM=="scsi_generic", SYSFS{type}=="8", PROGRAM="scsi_id -g
-u -s %p", RESULT=="1ADIC_A0C0081018_LLA_", SYMLINK+="changer-ml6000"
KERNEL=="nst*", SUBSYSTEM=="scsi_tape", PROGRAM=="/usr/bin/sginfo -s %N",
RESULT=="*F0A1BBC004*", SYMLINK+="tape1-ml6000"
KERNEL=="nst*", SUBSYSTEM=="scsi_tape", PROGRAM=="/usr/bin/sginfo -s %N",
RESULT=="*F0A1BBC000*", SYMLINK+="tape0-ml6000"
-------------------------------------
The multipath rules use the "scsi_id" and "sginfo" programs to query each
"sg*" device and each "nst*" device for unique identifiers (the model/serial
number for the changer, the fibre WWN for each tape device), and then sets
symbolic links using our naming convention.
Regardless of the /dev/nst* device number, or which multipath to the hardware
is discovered first, /dev/tape0-ml6000 will always be a symbolic link to the
tape drive with the fibre WWN containing the string "F0A1BBC000". I manually
determined that this string will correspond to drive 0.
I hope this helps.
Mark
=> Patti Clark
=> Information International Associates, Inc.
=> Linux Administrator and subcontractor to:
=> Research and Development Systems Support Oak Ridge National Laboratory
=>
=>
----
Mark Bergman voice: 215-662-7310
mark.berg...@uphs.upenn.edu fax: 215-614-0266
System Administrator Section of Biomedical Image Analysis
Department of Radiology University of Pennsylvania
PGP Key: https://www.rad.upenn.edu/sbia/bergman
----- Text below this line was added without my consent -----
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
