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