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

[Tim Mooney]

In regard to: Re: finding storage at boot on luns other than 0 (sparse...:

>> 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?
>
> 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.

Thanks Herta.

That's more or less the "temporary solution" we have in place right now.
We just added the appropriate "echo" commands redirected into the
appropriate /sys file into the /etc/rc.d/rc.sysinit script, but that's
a hack.  We have to have the initscripts RPM on the yum skip list,
otherwise our customizations will be clobbered by an initscripts update
through Red Hat Network and the next reboot will fail until we
reimplement them.

I just figured there had to be a better, cleaner solution to do what we
needed to do.

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