CAM, SCSIn/iSCSI & LUNs

[Scott Long]

Danny Braniss wrote:

>>Danny Braniss wrote:
>>
>>>hi,
>>>	it seems that one of the differences between the SCSI1/2/3/4/i
>>>is the size of the LUN :-)
>>>
>>>Now, it seems that the CAM will search sequencially for LUNs, from 0 -> max_lun
>>>which i don't think will scale nicely.
>>>
>>>is there a way to tell the cam to do a scsi report luns command, instead of
>>>the sequential search?
>>>
>>>danny
>>>
>>>
>>
>>I, Matt Jacob, and Ken Merry talked about implementing REPORT_LUNS a 
>>couple of months ago, but it stalled for a reason that I cannot recall.
>>
>>Scott
> 
> 
> i was wondering, it would be nice, if setting in XPT_PATH_INQ response
> cpi->max_lun = -1, which would trigger the REPORT_LUNS ...
> 

That's not a very good general purpose solution.  While it probably
would work without problems for an iSCSI SIM, it doesn't work well for
a normal SCSI SIM.  The ability of a target to accept a REPORT_LUNS
command is a property of the target, not a property of the SIM, and
normal SCSI targets have a wide range of capabilities and limitations.
So it should be up to the scsi probe code to determine on a
target-by-target basis whether a REPORT_LUNS should be sent or if the
luns should be linearly scanned.

I think that our previous discussion on how to implement REPORT_LUNS got
tangled up in trying to guess the proper heuristics for knowing whether
to do a scan or a REPORT_LUNS command, how to fall back if one or the
other fails, etc, i.e. we got caught up in the details.  If people have
FC, SCSI, and iSCSI targets that support multiple luns then we should
just write a prototype implementation and refine it from there.

Actually, now that OpenSolaris is available, it might be good to peek in
there for ideas on the heuristics.  I'd trust that code a whole lot more
than I'd trust Linux.

> next question:
> 	when a target/unit is lost it seems that the luns > 0 have to be
> 	removed/cleared by the sim, shouldn't it be done by the CAM?

I would think that sending an AC_LOST_DEVICE event with a path
containing the proper bus and target but a wildcard lun/device id would
do the right thing.  If not then it's definitely something that should
be looked into.

Scott