6

I have a Quantum SuperLoader 3 plugged in via SAS to a CentOS 7 system. It shows in dmesg and lsscsi and is handled by the ch driver.

$ lsscsi
[0:2:0:0]    disk    LSI      MR9271-8i        3.24  /dev/sda
[1:0:0:0]    tape    IBM      ULTRIUM-HH6      E4J1  /dev/st0
[1:0:0:1]    mediumx QUANTUM  UHDL             0091  /dev/sch0

Here's the kernel initialization:

$ dmesg
[   13.443589] scsi 1:0:0:0: Attached scsi generic sg2 type 1
[   13.444091] scsi 1:0:0:1: Attached scsi generic sg3 type 8
[   13.463023] SCSI Media Changer driver v0.25
[   13.463121] st: Version 20101219, fixed bufsize 32768, s/g segs 256
[   13.572514] ch0: type #1 (mt): 0x0+1 [medium transport]
[   13.572516] ch0: type #2 (st): 0x100+16 [storage]
[   13.572517] ch0: type #3 (ie): 0x0+0 [import/export]
[   13.572518] ch0: type #4 (dt): 0x20+1 [data transfer]
[   13.697117] ch0: dt 0x20: ch0: ID/LUN unknown
[   13.697119] ch0: INITIALIZE ELEMENT STATUS, may take some time ...
[   67.097903] ch0: ... finished
[   67.097910] ch 1:0:0:1: Attached scsi changer ch0
[   67.098792] st 1:0:0:0: Attached scsi tape st0
[   67.098796] st 1:0:0:0: st0: try direct i/o: yes (alignment 4 B)

The tape drive operates normally using the mt-st package. I have also installed mtx for use with Bacula or Amanda, but mtx seems to expect a different driver than ch.

It appears there are certain tools for the ch driver, such as scsi-changer, but they do not appear to be commonly used and so I imagine there must be a way to get mtx to work with the ch driver directly.

When invoked the obvious way:

$ sudo mtx -f /dev/sch0 status
/dev/sch0 is not an sg device, or old sg driver

/dev/sch0 is:

$ ls -lastZ /dev/sch0
crw-rw----. root cdrom system_u:object_r:device_t:s0    /dev/sch0

I'm going to try using the kraxel.org SCSI changer, but given the lack of support within Amanda, any suggestions to solve the mtx issue would be a boon.

7

Figured it out!

mtx functions only on "generic" SCSI devices. The /dev/sch0 device provided by the ch kernel driver is something of a red herring.

It turns out that SCSI devices are given "generic" device files, in addition to whatever driver-backed specific devices are created. You can find those using lsscsi:

$ lsscsi --generic
[0:0:19:0]   enclosu CISCO    UCS 240          0809  -          /dev/sg0
[0:2:0:0]    disk    LSI      MR9271-8i        3.24  /dev/sda   /dev/sg1
[1:0:0:0]    tape    IBM      ULTRIUM-HH6      E4J1  /dev/st0   /dev/sg2
[1:0:0:1]    mediumx QUANTUM  UHDL             0091  /dev/sch0  /dev/sg3

These were actually alluded to in the dmesg output above. Using the generic device, mtx works fine with the SuperLoader 3 on CentOS 7:

$ sudo mtx -f /dev/sg3 status
  Storage Changer /dev/sg3:1 Drives, 16 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
      Storage Element 1:Empty
      Storage Element 2:Empty
      Storage Element 3:Empty
      Storage Element 4:Empty
      Storage Element 5:Empty
      Storage Element 6:Empty
      Storage Element 7:Empty
      Storage Element 8:Empty
      Storage Element 9:Empty
      Storage Element 10:Empty
      Storage Element 11:Empty
      Storage Element 12:Empty
      Storage Element 13:Empty
      Storage Element 14:Empty
      Storage Element 15:Empty
      Storage Element 16:Empty

All that's left to do is to symlink /dev/changer to /dev/sg3 for convenience.

  • Welcome to Unix.SE! Please accept your own answer so your question can be correctly identified as having a solution. – Stephen Kitt Mar 30 '15 at 21:56
0

I wanted to add some additional information and an alternate method for operators who might add or remove disks and other SCSI devices, only to find that the /dev/sgX device they previously configured within bacula has changed after reboot. Bacula has syntax for running shell commands to import other configuration files which will help us get what we need. This syntax is listed in section 18.2.3 of the "Main" manual for Bacula 9.4.

First create a script:

cat > /usr/local/libexec/bacula-get-generic-changer-device << XYZZY
#!/bin/sh
echo -n Changer Device = \$(/usr/bin/lsscsi -g |/usr/bin/grep 'mediumx.*IBM.*3573-TL.*/dev/sch' |/usr/bin/sed 's|^.*/dev/\(sg[0-9]\)|/dev/\1|')
XYZZY
chmod 700 /usr/local/libexec/bacula-get-generic-changer-device

You must modify the regular expression above to match your tape library. I have a Dell TL2000 which is really a rebranded IBM 3573-TL. It shows up like this when queried through lsscsi:

[6:0:0:1]    mediumx IBM      3573-TL          F.11  /dev/sch0  /dev/sg6

When you run the script, its output should be similar to the following; check that it's right for your system:

# /usr/local/libexec/bacula-get-changer-generic-device
Changer Device = /dev/sg6# 

You'll notice that there's no trailing newline and the prompt immediately follows the generic device name. This is what we want. Now all that remains is to change the "Changer Device" lines in bacula-sd.conf. Replace them with the following:

@|"sh -c /usr/local/libexec/bacula-get-changer-generic-device"

Now bacula will have the correct generic SCSI device of your tape library / autochanger on every boot, even if other SCSI devices have been added or removed from your system.

Edit: Of course, just after I figured out this method, it seems there's an easier way. You can check /dev/tape/by-id/ and use the appropriate device. In my case, it looks like this:

/dev/tape/by-id/scsi-1IBM_3573-TL_00X2U49P1785_LL0 -> ../../sg6

And it has the added benefit of being able to distinguish the logical libraries from one another (_LL0).

-1

You need to load kernel module sg on centos 7 (It was reported as bug):

# modprobe sg
# lsscsi --generic
# mtx -f /dev/sgX status

(SCSI generic driver not loading at boot) https://www.centos.org/forums/viewtopic.php?f=48&t=52357

  • It is pretty clear from the already accepted answer from months ago that the sg driver is already loaded. – psusi Nov 21 '15 at 0:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.