iSCSI/luns/check-condition

[Scott Long]

William Studenmund wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Aug 25, 2006, at 1:59 PM, Scott Long wrote:
> 
>> Kenneth D. Merry wrote:
>>
>>> On Fri, Aug 25, 2006 at 11:37:15 -0700, William Studenmund wrote:
>>> See above...CAM sets the LUN number when it does the initial probe  of a
>>> LUN, and when the LUN reports it is SCSI-2 or below.
>>> The problem with rejecting the LUN number on the inquiry is that the
>>> initiator is issuing the inquiry to find out what SCSI rev the  
>>> target is in
>>> the first place.  It has to do so in a way that will work on old  and 
>>> new
>>> targets.
>>> Things work okay on LUN 0, because the LUN field is set to 0.
>>> My suggestion would be to allow setting of the LUN number on the  
>>> inquiry
>>> command only.  That way the initiator can figure out what SCSI rev  
>>> you are
>>> and do things accordingly.
>>> Ken
>>
>>
>> Are there cases where a target has multiple LUNs that will each  
>> report a different SCSI rev?  If not, then CAM should look at the  rev 
>> of LUN 0 of the target when deciding how to form an INQ of LUNs  >0.
> 
> 
> While I think there could be a difference between reported levels, if  
> LUN 0 reports > SCSI-1, then I think it's appropriate to not put the  
> LUN in the CDB. SCSI-2 mentions that the LUN field should be set to  
> zero as SCSI-3 may reclaim the bits (which it did).
> 
> I believe that by the time LUN 0 has been probed, the system should  
> have enough information to figure out if the device is SCSI-1,  SCSI-2. 
> or SCSI-3 (i.e. sam-X, spc-Y, etc.). I think that Scott's  suggestion is 
> good; if LUN 0 is SCSI-1, fill in the LUN in the CBD.  If LUN 0 is > 
> SCSI-1, don't.
> 
> Also, while probing LUN 0, it's probably best to perform a REPORT  LUNS 
> command. If it succeeds, you 1) don't need to blindly probe, and  2) you 
> know that you shouldn't put the LUN in the CDB (REPORT LUNS  appeared  
> in SPC, which is SCSI-3).
> 

The REPORT_LUNS angle has been discussed many times in the past.  The 
problem is that it's a risky command without the right heuristics. 
Older SCSI devices are notorious for going down in flames if given a
CDB that they don't understand, so we can't universally send a 
REPORT_LUNS to every target that responds on LUN 0.  We've discussed
adding some heuristics to look at the rev field and decide from there,
but that's only part of the problem.  The other part of the problem 
involves tackling the CAM probe state machine to handle both the
current sequential scan as well as a REPORT_LUNS enumeration.  That's
not an exceptionally hard task, it just takes a bit of work.

Scott