Re: UNH Plugfest

["Julian Satran" <Julian_Satran@il.ibm.com>]

Bob,

Thanks for the great work at the plugfest.

As for the question at hand - I think you did see already two opinions, that I tend to agree with, that those poor souls that still rely on the the CDB LUN should fix their drivers.

We tried hard to avoid having to look inside the CDB all over iSCSI (we don't even have to look inside to determine the length and that was considered too at a point) and I don't see any good reason to break this rule.

Thanks,
Julo

"Robert D. Russell" <rdr@io.iol.unh.edu> 15-02-02 00:11

To:        Julian Satran/Haifa/IBM@IBMIL         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.

Comments?


Bob Russell, UNH
Rod Harrison, Wind river