Subject: Re: Qlogic 2200
To: Dhananjoy Das 'Joy' <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/25/2002 15:24:13
In message <PGELKOPLGDAAEEPGAGNJAEKMCCAA.firstname.lastname@example.org>"Dhananjoy Das 'Joy'
>JOY> these are FC RAID groups (Mylex controller)
Oh. That means that each Mylex controller _probably_ responds to a
SCSI INQUIRY with a device type of 0x0c (possibly 0x0d), and maps the
disks (or RAID containers) onto separate LUNs.
Open-source SCSI-bus-scanning code is a bit ... simplistic. Linux,
*BSD all scan all SCSI IDs, and for each ID that responds to an
INQURY, they probe LUNs from 0, 1, ... until the device stops answering,
or until a "reasonable" upper-bound is hit (LUN 127 or 255).
Unfortunately, RAID controllers and FC enclosures often have
non-contiguous LUN mappings. They expect the end-host software to take
notice of the device-type in the INQUIRY response, and send a SCSI
REPORT LUNS command, to ask the RAID box which LUNs the RAID array is
prepared to offer this specific client. (Examples are for FC devices
which are zoning-aware, or which implement per-volume ACLs based on
I haven't tried a Mylex controller, but there are other devices on the
market where the *BSD/Linux strategy fails to successfully probe
volumes on a RAID controller; but the the REPORT LUNs followed by an
INQUIRY/TUR to each reported lun, *does* work. Seems like the ACL
machinery doesn't quite work right unless the REPORT LUNS is sent...
As of now, dev/scsipi/scsiconf.c ignores array and enclosure devices:
it doesn't recognize LUN 0 at all, and just tries to iterate through
all LUNs. For a high-quality solution we'd need to rework
scsi_probe_bus() and scsi_probe_device(), to separate the "what kind
of tdevice is this?" from the "iterate through known devices".
For devices recognised as arrays (or enclosures?), we shuold check
the ANSIlevel (or a quirks table), and if the device is new enough
to grok REPORT_LUNS, we shuld send it a REPORT_LUNS, then iterate
over scsi_probe_device for only the reported LUNs.
Otherwise, we should fall back to the nested for-loop.
(Manuel? Sound OK? Want to give it a shot?)