SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: UNH Plugfest



    Bob & Rod,
    
    The LUN field in the SCSI CDB is not used in SCSI-2 devices either. It was
    used in SCSI-1 devices. SCSI-2 mandates the use of the IDENTIFY message (for
    parallel scsi) to identify the LUN for a given SCSI command.
    
    For other SCSI transports like FC, etc the LUN is encapsulated in the
    PDU or IU that carries the SCSI Command. (ex : FCP_CMD, iscsi scsi command pdu,
    SRP_CMD, etc).
    
    The SCSI LUN Addressing information for each SCSI command is conveyed from the
    SCSI ULP to the SCSI LLP in some per I/O control block passed down from the
    SCSI ULP to the SCSI LLP.  (ex : scb, scsi_pkt, Srb, etc).
    
    Are there any O.S. SCSI implementations out there that do not do this and 
    instead, send the LUN in the SCSI CDB (?). 
    
    In any case, this sort of recommendation on where the LLP should get its LUN 
    addressing information from should belong to the SCSI driver writer's guide 
    of that O.S. and not in a protocol specification, IMHO.
    
    Regards,
    Santosh
    
    > 
    > Julian:
    > 
    > The last several days at the UNH plugfest have uncovered no major
    > issues relating to the standard.
    > 
    > One thing that was observed was that a number of implementations are
    > dealing with SCSI-2 systems, because most of the world (i.e., Windows)
    > is still based on SCSI-2.  The iSCSI standard clearly references the
    > SCSI-3 specifications.  However, perhaps we should consider how iSCSI
    > could be used with SCSI-2.
    > 
    > In particular, there is the issue of LUNs.  Some implementers are
    > expecting some SCSI-2 CDBs to carry a LUN number in the 3 high-order
    > bits of byte 1 in the CDB, and are not setting/using the LUN field
    > in the iSCSI PDU.  This is clearly wrong, although if both target and
    > initiator do it, then they interoperate with each other but not with
    > standard-conformant implementations.
    > 
    > Of course, there may be (and probably are) additional issues (besides
    > the LUN issue) that may arise.  However, it still might be useful to
    > warn implementers that this is an issue, and perhaps to suggest a
    > "conversion rule" that would allow SCSI-2 to interoperate with iSCSI.
    > 
    > One possibility for such a rule follows:
    > 
    > If an iSCSI initiator has to send a SCSI-2 PDU containing a LUN,
    > it should extract the LUN from the 3 high-order bits of CDB byte 1
    > and send that in the iSCSI LUN field (unless, of course, it has some
    > other means of obtaining the LUN value independent of the CDB, in which
    > case it should send that value in the iSCSI LUN field).
    > 
    > If an iSCSI target receives a SCSI-2 PDU containing a LUN, then if
    > the iSCSI LUN field is 0 it should extract the LUN value from the
    > 3 high-order bits of CDB byte 1 (which in the SCSI-3 case should always
    > be 0 anyway) and use that as the LUN value;
    > if the iSCSI LUN field is not 0 then it should use that as the LUN value.
    > 
    > At first glance this rule seems to allow an initiator and/or a target
    > to interoperate with both SCSI-2 and SCSI-3 systems.
    > 
    > Comments?
    > 
    > 
    > Bob Russell, UNH
    > Rod Harrison, Wind river
    > 
    
    
    -- 
    ##################################
    Santosh Rao
    Software Design Engineer,
    HP-UX iSCSI Driver Team,
    Hewlett Packard, Cupertino.
    email : santoshr@cup.hp.com
    Phone : 408-447-3751
    ##################################
    
    


Home

Last updated: Fri Feb 15 09:18:02 2002
8756 messages in chronological order