Linux – RHEL5 do not see sas tape library

autoloaderlinuxsastapedrive

We have a tape library which is connected to a server by SAS link. Server is running OS Linux. OS doesn't see the tape library in /proc/scsi/scsi . We tried to rescan scsi bus(*1), but it didn't help.

What could we do to access it?

PS:The main goal is just to see it connected to the server
We also have storage system connected to the same HBA. Servers,storage and library vendor – HP.

*1 – for each host we run echo '- – -' > /sys/class/scsi_host/hostN/scan

Best Answer

I'd like to see more detail. Please provide the server model, tape drive information and explain how it is onnected to the server. Which backup software suite will you be using?

In general, a SAS tape device should be connected to a dedicated SAS HBA. In most HP installations, this is really an LSI-based controller, so you'd be working with the mptfusion set of drivers. So grep -i mpt in your dmesg output and the relevant log files in /var/log...

If the driver/module is loaded, you don't need to rescan or do anything manual to recognize the drive.

This may be different if you're connected directly to an HP Smart Array controller... So please clarify.

Related Solutions

Linux – Fibre Channel LUN rescan and QLogic

In the off chance that the block device is being detected, but no /dev/ device is being created, you can manually create the device. This isn't optimal, but might limp you along. The major and minor numbers are presented in /proc/partitions, and you can create your own block devices through the mknod command.

 # mknod /dev/sdg4 104 17

However, I feel your pain. QLogic offers driver download for RHEL and SUSE but it seems no other distros. OpenSUSE just might have the QLogic-branded drivers but I can't be certain of it. I'll check closer when I get to work.

Edit: I'm at work, and it does seem that the QLogic drivers on my SLES boxes are all the QLogic supplied one. Their OS support grid:

http://filedownloads.qlogic.com/files/Driver/71098/readme_driver_80223.html#os_support

And yet, when I download the bog-standard 2.6.27.25 kernel and look in the ./drivers/scsi/qla2xxx/qla_version.h file it is nearly the same version numbers as I have on my Novell distros (both SLES, and the free openSUSE). Which suggests that the solution you found for SLES/RHEL may actually work with a standard 2.6.27.25 kernel.

Linux – Understanding Linux SCSI queue depths

Usually the queue depth is per LUN/path, in rr multipathing configurations. It's very dependent on the implementation of the multipathing driver and you would have to check with the documentation of your multipathing driver which in your case is the device mapper's multipathing wich AFAIR uses the same concept as ESX in which the queue depth for all paths it the smallest queue depth for any of the paths see my example from ESX here:

ESX's native multipathing configures the queue depth in rr multipathing configurations to be the smallest common depth of any of the involved queues. Ie with a depth of 32 for each LUN/path and 4 paths the total queue depth is only 32! That's the reason why some vendors offer their own driver (like EMC's powerpath). From a performance perspective the round robing load distribution ESX doesn't cycle over any given path for each IO, the default schedules the first 1000 IOs go over the first path, the next 1000 IOs over the next on a per VM basis which should smooth the overall load over all paths as an per single IO path switch would incur a latency penalty for each IO.

Best Answer

Related Solutions

Linux – Fibre Channel LUN rescan and QLogic

Linux – Understanding Linux SCSI queue depths

Related Topic