Arunav Mandal wrote:
> I have a Tandberg T40+ Tapeloader with HP LTO-5 tape drive connected to
> "QLogic Corp. ISP2532-based 8Gb Fibre Channel to PCI Express HBA" on a Dell
> 2950 running Ubuntu Server 10.10. The kernel version is 2.6.35-24-server.
> The autoloader device number changes sometimes with reboot. When I installed
> the server it was /dev/sg4 and now it is /dev/sg2. The tape drive is at
> /dev/st0 and /dev/nst0. 

the SG number depends entirely on the order things are picked up in. So 
does ST/NST for that matter. The trick there is to use a script to link 
each detecetd ST to a WWID entry and use that in bacula-sd.conf

Bacula does use ST - more specifically it locks to whatever you have 
defined in bacula-sd - which means if you put an incorrect entry it will 
use it (GIGO)

> My question is how can I fix the problem of device number changing with
> reboots?

Like this (from my configuration on RHEL5.5):

bacula-sd.conf

[snip]
Device {
   Name = MSSLY8-0
   Drive Index = 0
   Device Type = Tape
   Media Type = LTO5
   AutoChanger = yes;
   Changer Device = /etc/bacula/DEVICES/MSSLY8-changer
   Archive Device = /etc/bacula/DEVICES/MSSLY8-0
   AutomaticMount = yes;               # when device opened, read it
   AlwaysOpen = yes;
   LabelMedia = yes;                   # lets Bacula label unlabeled media
   RemovableMedia = yes;
   RandomAccess = no;
   Volume Poll Interval = 7200
   Alert Command = "sh -c '/usr/local/bin/gettapeinfo.sh 
/etc/bacula/DEVICES/MSSLY8-0'"
   Spool Directory = /var/bacula/spool/MSSLY8-0
   Maximum File Size = 10GB
   Maximum Network Buffer Size = 65536
   Maximum Spool Size     = 250G
   Maximum Job Spool Size = 50G
}
[snip]

The /etc/bacula/DEVICES entries are there simply for readability and are 
symlinks to the WWIDs of the tapes:

# ls -l /etc/bacula/DEVICES
total 0
lrwxrwxrwx 1 root root 42 Nov 18 14:45 MSSLY8-0 -> 
/dev/tape/by-id/scsi-3500110a001313fee-nst
lrwxrwxrwx 1 root root 42 Nov 18 14:45 MSSLY8-1 -> 
/dev/tape/by-id/scsi-3500110a0013141aa-nst
lrwxrwxrwx 1 root root 42 Nov 18 14:45 MSSLY8-2 -> 
/dev/tape/by-id/scsi-3500110a001314b4a-nst
lrwxrwxrwx 1 root root 42 Nov 18 14:42 MSSLY8-3 -> 
/dev/tape/by-id/scsi-3500110a001314b12-nst
lrwxrwxrwx 1 root root 42 Nov 18 14:50 MSSLY8-4 -> 
/dev/tape/by-id/scsi-3500110a0013144e2-nst
lrwxrwxrwx 1 root root 42 Nov 18 15:00 MSSLY8-5 -> 
/dev/tape/by-id/scsi-3500110a0013132b6-nst
lrwxrwxrwx 1 root root 42 Nov 18 15:04 MSSLY8-6 -> 
/dev/tape/by-id/scsi-3500110a00131426e-nst
lrwxrwxrwx 1 root root 38 Oct 29 20:47 MSSLY8-changer -> 
/dev/tape/by-id/scsi-200900d0710200002

# ls -l /dev/tape/by-id/
total 0
lrwxrwxrwx 1 root root 10 Dec 23 19:15 scsi-200900d0710200002 -> ../../sg46
lrwxrwxrwx 1 root root 10 Dec 23 19:15 scsi-3500110a0013132b6-nst -> 
../../nst9
lrwxrwxrwx 1 root root 10 Dec 23 19:14 scsi-3500110a001313fee-nst -> 
../../nst4
lrwxrwxrwx 1 root root 11 Dec 23 19:15 scsi-3500110a0013141aa-nst -> 
../../nst11
lrwxrwxrwx 1 root root 10 Dec 23 19:14 scsi-3500110a00131426e-nst -> 
../../nst6
lrwxrwxrwx 1 root root 10 Dec 23 19:14 scsi-3500110a0013144e2-nst -> 
../../nst3
lrwxrwxrwx 1 root root 11 Dec 23 19:15 scsi-3500110a001314b12-nst -> 
../../nst10
lrwxrwxrwx 1 root root 11 Dec 23 19:16 scsi-3500110a001314b4a-nst -> 
../../nst13

Note that only the SG of trhe changer is listed above. That's where 
/usr/local/bin/gettapeinfo.sh comes in to find the sg of individual tape 
  drives for reporting purposes:

===
#!/bin/bash
export INDIRECT=`ls -l $1 | cut -f2 -d\>`
export DEVICE=`ls -l $INDIRECT | cut -f2 -d\>  | cut -f3 -d/`
export GENERIC=`ls /sys/class/scsi_tape/$DEVICE/device | grep 
scsi_generic | cut -f2 -d:`

echo $1 $INDIRECT $DEVICE $GENERIC

tapeinfo -f /dev/$GENERIC
smartctl -H -d scsi -l error /dev/$GENERIC
===

Ideally RHEL's udev rules would put the sg entry in /dev/tape/by-id and 
I wouldn't have to kludge the script...

NOTE: Linux multipathing does NOT support generic or tape devices, so be 
careful what you disconnect in a fibre network!



------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users