On Monday 26 March 2007, FL wrote:
>Executive summary:
>mt status works if no tape is loaded!
>
>
>Details:
>This is what I have done so far (I will try the suggestion to echo the
> new device into /proc/scsi)
>
>added a the last line to /etc/modprobe.conf as follows:
>[root@amanda ~]# tail /etc/modprobe.conf
>alias eth0 3c59x
>alias scsi_hostadapter aic7xxx
>alias usb-controller uhci-hcd
>alias scsi_hostadapter1 aic79xx
>options scsi_mod max_luns=255
>[root@amanda ~]#
>
>(in my version of CentOS, which is close to RHEL 4,
>what was previously
> options scsi_mod max_scsi_luns=255
>became
> options scsi_mod max_luns=255)
>
>Then I created a new initial ram disk with
>
>
>mkinitrd /boot/initrd-2.6.9-42.0.10.ELsmpLUN.img 2.6.9-42.0.10.ELsmp
>
>and modified /boot/grub/menu.lst accordingly.
>
>But nothing sort of worked until I located the SCSI terminator.
This is very important. Missing or improper terms has caused the wasted
sacrifice of lots of virgins over the last 30 or so years we've had a
scsi spec. Few people understand that this is in fact a transmission
line, and as such it _must_ be terminated at both _ends_ of the physical
cable. Using the next connector on the cable, and leaving another foot
or so curled up and unused at the end will cause data trashing echo's and
cost you any religion you may have thought you had.
>Now something odd occurs: with say storage element 4 loaded into the
> drive,
>
>[root@amanda ~]# mtx -f /dev/sg4 status
> Storage Changer /dev/sg4:1 Drives, 11 Slots ( 0 Import/Export )
>Data Transfer Element 0:Full (Storage Element 4 Loaded):VolumeTag =
>A00004
> Storage Element 1:Full :VolumeTag=A00001
> Storage Element 2:Full :VolumeTag=A00002
> Storage Element 3:Full :VolumeTag=A00003
> Storage Element 4:Empty:VolumeTag=
> Storage Element 5:Full :VolumeTag=A00005
> Storage Element 6:Full :VolumeTag=A00006
> Storage Element 7:Full :VolumeTag=A00007
> Storage Element 8:Full :VolumeTag=A00008
> Storage Element 9:Full :VolumeTag=A00009
> Storage Element 10:Full :VolumeTag=A00010
> Storage Element 11:Full :VolumeTag=A00011
>[root@amanda ~]#
>
>I cannot see the status:
>
>[root@amanda ~]# mt -f /dev/nst2 status
>/dev/nst2: Input/output error
>[root@amanda ~]#
>
>But if I unload the tape drive I CAN see the status
>
>[root@amanda ~]# mtx -f /dev/sg4 unload 4
>Unloading Data Transfer Element into Storage Element 4...done
>[root@amanda ~]#
>
>[root@amanda ~]# mtx -f /dev/sg4 status
> Storage Changer /dev/sg4:1 Drives, 11 Slots ( 0 Import/Export )
>Data Transfer Element 0:Empty
> Storage Element 1:Full :VolumeTag=A00001
> Storage Element 2:Full :VolumeTag=A00002
> Storage Element 3:Full :VolumeTag=A00003
> Storage Element 4:Full :VolumeTag=A00004
> Storage Element 5:Full :VolumeTag=A00005
> Storage Element 6:Full :VolumeTag=A00006
> Storage Element 7:Full :VolumeTag=A00007
> Storage Element 8:Full :VolumeTag=A00008
> Storage Element 9:Full :VolumeTag=A00009
> Storage Element 10:Full :VolumeTag=A00010
> Storage Element 11:Full :VolumeTag=A00011
>[root@amanda ~]#
>[root@amanda ~]# mt -f /dev/nst2 status
>SCSI 2 tape drive:
>File number=-1, block number=-1, partition=0.
>Tape block size 0 bytes. Density code 0x0 (default).
>Soft error count since last status=0
>General status bits on (50000):
> DR_OPEN IM_REP_EN
>[root@amanda ~]#
I'm wondering if RHEL has continued the practice of only scanning the scsi
bus for LUN=0, in which case many libraries and changers will be missed.
This requires a rebuild of the kernel, with the 'scan all luns' set to 'y'
in the scsi menu.
I would however, scan the /var/log/dmesg file to see if /dev/nst2 is the
correct address for the tape drive, which may not be the same as the
changer robot you are running with the mtx command. You're use
of /dev/sg4 to address the robot, but /dev/nst2 for the drive looks like
something I'd want to check.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Everything that you know is wrong, but you can be straightened out.
|
