Linux – Fibre Channel LUN rescan and QLogic

fibre-channellinuxqlogicstoragestorage-area-network

I have a serious problem with a SAN storage array connected to a Linux box through Fibre Channel. Here is the configuration :

  • Debian with plain vanilla linux 2.6.27.25
  • Fibre controller QLogic 4Gb dual port ( ISP2432 based)

Basically the problem is: how to get this #?@!! FC controller/driver to recognize properly configuration changes (new or removed LUNs) of the storage array?

  1. when I create a new LUN on my array (typically a snapshot of some existing LUN) and map it to my HBA, I can't get it recognized properly : rescan-scsi-bus -l -w -r actually detects something ( a generic /dev/sgXX device) however no block device is created ( /dev/sdXX).

  2. same thing when issuing a LIP and rescan manually:

    echo 1 > /sys/class/fc_host/host6/issue_lip

    echo "- – -" > /sys/class/scsi_host/host6/scan

  3. if I remove an existing LUN, neither issuing LIPs and rescans or rescan-scsi-bus have any effect. The previous devices remain there and of course don't work ( "file -s /dev/sdXX -> I/O error").

  4. reloading the qla2xxx driver works. However it's completely unworkable in a production environment.

Apparently this is a very common problem with QLogic. Some sort of solution exists that works only when using the QLogic issued driver available only for RedHat and Suse enterprise distros : see this explanation.

Additional info :

Here is the scsi devices before LIP and rescan:

# sg_map -x
/dev/sg0  0 0 0 0  0  /dev/sda
/dev/sg1  0 0 1 0  5  /dev/scd0
/dev/sg2  1 0 0 0  0  /dev/sdb
/dev/sg3  6 0 0 0  0  /dev/sdc
/dev/sg4  6 0 0 1  0  /dev/sdd
/dev/sg5  6 0 0 2  3

After a LIP and rescan, I have a new sg device, but no matching drive. If I reload the driver, a drive appear:

# sg_map -x
/dev/sg0  0 0 0 0  0  /dev/sda
/dev/sg1  0 0 1 0  5  /dev/scd0
/dev/sg2  1 0 0 0  0  /dev/sdb
/dev/sg3  6 0 0 0  0  /dev/sdc
/dev/sg4  6 0 0 1  0  /dev/sdd
/dev/sg5  6 0 0 2  3
/dev/sg6  6 0 0 3  3

~# sg_map -x
/dev/sg0  0 0 0 0  0  /dev/sda
/dev/sg1  0 0 1 0  5  /dev/scd0
/dev/sg2  1 0 0 0  0  /dev/sdb
/dev/sg3  8 0 0 0  0  /dev/sdc
/dev/sg4  8 0 0 1  0  /dev/sdd
/dev/sg5  8 0 0 2  0  /dev/sde
/dev/sg6  8 0 0 3  3

Edit: OK, obviously this is a tough nut to crack. I'll ask the LKML and report here.

Best Answer

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.

Related Topic