SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI UNH Plugfest



    > The iSCSI initiator driver should clean up the CDB as needed
    > (your first
    > suggestion) and keep the wire protocol clean.  If it's in an OS
    > generating old CDBs, it knows that and is best suited to fix them.
    > Don't burden the iSCSI targets with any of this.
    
    I don't agree that the iSCSI initiator should touch the CDB. This is a ULP
    issue and the issuer of the CDB should use or not use the bits as desired.
    
    Maybe that is what you meant. 
    
    Eddy
    
    -----Original Message-----
    From: ERICKSON,SHAWN (HP-Roseville,ex1) [mailto:shawn_erickson@hp.com]
    Sent: Friday, February 15, 2002 12:17 PM
    To: 'Elliott, Robert'; ips@ece.cmu.edu
    Subject: RE: iSCSI UNH Plugfest
    
    
    > -----Original Message-----
    > From: Elliott, Robert [mailto:Robert.Elliott@compaq.com]
    > Sent: Thursday, February 14, 2002 6:58 PM
    > To: ips@ece.cmu.edu
    > Subject: RE: iSCSI UNH Plugfest
    >
    >
    > Although those bits are often reserved, some commands use them (e.g.
    > SEND DIAGNOSTIC).  It's not safe to guess that they contain a
    > 3 bit LUN
    > value.
    
    Correct.
    
    > The iSCSI initiator driver should clean up the CDB as needed
    > (your first
    > suggestion) and keep the wire protocol clean.  If it's in an OS
    > generating old CDBs, it knows that and is best suited to fix them.
    > Don't burden the iSCSI targets with any of this.
    
    I second that!
    
    > The UNH test suite should check for compliance for this and
    > other basic
    [snip]
    > * logical units implement VPD pages 80h and 83h
    >   * 80h unit serial number
    >   * 83h NAA type IEEE Registered or IEEE Registered Extended
    
    Yes, please do. The world will be a better place for storage administrators,
    your customers will love you.
    
    > * initiators don't send TARGET RESETs
    
    Yes, please do. Disruptive in multi-initiator environments (which is mostly
    the domain of FC & iSCSI).
    
    > * initiators use logical unit VPD data to identify logical units, not
    > the dynamic fabric/bus address of the target
    
    YES, please do. Again your customers will love you!
    
    -Shawn
    
    > > -----Original Message-----
    > > From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
    > > Sent: Thursday, February 14, 2002 4:12 PM
    > > To: Julian Satran
    > > Cc: ips@ece.cmu.edu
    > > Subject: Re: UNH Plugfest
    > >
    > >
    > > 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.
    >
    >
    


Home

Last updated: Mon Feb 25 14:18:05 2002
8878 messages in chronological order