finding storage at boot on luns other than 0 (sparse luns)

[Herta Van den Eynde]

2008/7/30 Tim Mooney <Tim.Mooney at ndsu.edu>:
>
> We have a variant of the SCSI "sparse lun" problem, and I would like some
> advice on what the recommended method is to work around it.  Searching
> for "sparse lun" and various other keywords related to it turns up lots
> of hits in the search engines, but most of them are old and none of them
> seem to work reliably with recent RHEL.
>
> The systems in question are RHEL 5.2, completely up to date.  The boxes
> get some storage via a pair of connections through a dual-port QLx2xxx
> FC card.  The problem is that the storage appears on a lun other than 0
> (there's nothing on lun 0):
>
> $cat /proc/scsi/scsi Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
>  Vendor: SEAGATE  Model: ST336807LC       Rev: 0C01
>  Type:   Direct-Access                    ANSI  SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 03 Lun: 00
>  Vendor: SEAGATE  Model: ST336807LC       Rev: 0C01
>  Type:   Direct-Access                    ANSI  SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 06 Lun: 00
>  Vendor: ESG-SHV  Model: SCA HSBP M29     Rev: 1.06
>  Type:   Processor                        ANSI  SCSI revision: 02
> Host: scsi2 Channel: 00 Id: 00 Lun: 04
>  Vendor: MAYASTOR Model: lvm(58,3)        Rev: 0.9
>  Type:   Direct-Access                    ANSI  SCSI revision: 03
> Host: scsi3 Channel: 00 Id: 00 Lun: 04
>  Vendor: MAYASTOR Model: lvm(58,4)        Rev: 0.9
>  Type:   Direct-Access                    ANSI  SCSI revision: 03
>
>
> The storage on scsi2, target 0, lun 4 and scsi3, target 0, lun 4 are part
> of a md RAID1 mirror pair.  That md RAID1 device fails to assemble on system
> startup, because the system never detects the two volumes that make up the
> md device.
>
> If we manually echo the appropriate value into the
>
>        /sys/class/scsi_host/hostN/scan
>
> file, then the device shows up.  If we do it for both devices, we can then
> assemble the array manually.
>
> The question is, how do we get this to happen automatically during the
> startup process, and early enough so that the devices are available for
> md startup?
>
> We tried adding
>
>        options scsi_mod default_dev_flags=0x240
>
> to /etc/modprobe.conf and then rebuilding the initrd, where
>
>        0x200 = Scan for large LUNs
>        0x040 = Handle sparse LUN numbering
>
> That does indeed force the system to scan for sparse luns, but the
> problem is that it now scans for lun numbers > 16,384, and the fibre
> targets that are providing this storage don't react well to that.  In
> this case we don't need the system to scan past lun 7, but we have other
> systems with this exact same problem where the storage is on e.g. lun 11,
> so we need a solution that doesn't stop probing sparse luns at lun 7.
>
> I also tried leaving out the 0x200 but instead specifying max_luns, so
> we could control what the highest lun number was that the system scanned
> for, but I wasn't able to make that work in coordination with
> default_dev_flags=0x040 in /etc/modprobe.conf.
>
> Am I on the right track, or is there some other supported method with
> RHEL 5.x to get the system to detect sparse luns at boot time, early
> enough to use those devices as part of LVM or md?
>
> Thanks,
>
> Tim
> --
> Tim Mooney                                             Tim.Mooney at ndsu.edu
> Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
> Room 242-J6, IACC Building                             701-231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
>
Hi Tim,

Last time I had a system like this, I simply edited the system startup
and shutdown scripts to assemble the array at the proper time.  The
attached .pdf has the instructions for a Red Hat 4 system.  You'll
probably have to modify some details, but it should be easy to figure
out what.

Hope this helps.

Kind regards,

Herta


-- 
"Life on Earth may be expensive,
 but it comes with a free ride around the Sun."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: md.pdf
Type: application/pdf
Size: 75002 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/redhat-sysadmin-list/attachments/20080730/e9734578/attachment.pdf>