Re: Report luns [was: Apple Xserve RAID and qlogic ISP2312 (qla2300)]

[Douglas Gilbert <dougg@torque.net>]

Luben Tuikov wrote:
> Douglas Gilbert wrote:
> 
>> So if that fails scsi_scan.c might issue a REPORT LUNS command to
>> this lun: 0xc101 which is the value of the REPORT LUNS well-known lu.
> 
>  > Note that this is a 16 bit quantity (not 64 bit as I said in a
> 
>> previous post about luns). For simplicity let us assume that
>> that it is at the top level. [If a device returns HiSup=1 in its
>> standard INQUIRY response then it claims to support a 4 level
>> hierarchy in its luns (with 16 bits in each level).]
> 
> 
> And also supports REPORT LUNS.
> 
> So in either case, we send REPORT LUNS to LUN 0 and if
> this fails to REPORT LUNS W-LUN (0xC101...).
> 
> Since the standard says that depending on the transport
> protocol LUNs are either 16 or 64 bit values, how do
> we decide this from SCSI Core/app. client?  Wouldn't it
> be better to just send 64 bits with bytes 2 to 7 all 0-ed?
> 
> So in general SCSI Core always uses 64 bits and the LLDD
> decides between 16 and 64 bits, since the transport could
> be messier.
> 
>> So if a modern SCSI enclosure or bridge uses well known lus
>> rather than the lun 0 hack, how will applications in linux
>> access them? They are certainly not block devices.
> 
> 
> Ah, good question.  No, they cannot be block devices since
> they are not mountable.  But they are _addressable_ devices.
> 
> If it is decided to not create a new OS type, then those
> could be char devices on the bus, and accessed via sg.
> 
> If it is decided to create a new OS type, then 'a' would
> be appropriate to denote addressable devices, again
> being accessed via sg.  Do you think expanders could
> be represented by those device types too?

Luben,
I liked the way bsg had a single char device and used
a bind mechanism. However it is only possible to bind
to an existing block device.

SAS expanders (or at least their SMP target ports) are
a similar problem to W-LUNs. Namely we have no way to
"talk" to them from the user space currently in Linux.
SMP is not a SCSI command set (but it is close). Even if
sg could issue SMP commands, I'm not sure the scsi mid
level would be helpful when error conditions occurred
(e.g. SMP command timeout).

As for the addressability problem, sockets and connect
calls come to mind.

Doug Gilbert