In message <PGELKOPLGDAAEEPGAGNJAEKMCCAA.joy@quartetns.com>"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
client WWN).

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