On Tue, 2005-09-13 at 15:25 -0700, Patrick Mansfield wrote: > On Tue, Sep 13, 2005 at 05:02:36PM -0400, Luben Tuikov wrote: > > On 09/13/05 16:36, Matthew Wilcox wrote: > > > On Tue, Sep 13, 2005 at 04:23:42PM -0400, Luben Tuikov wrote: > > > > > >>A SCSI LUN is not "u64 lun", it has never been and it will > > >>never be. > > >> > > >>A SCSI LUN is "u8 LUN[8]" -- it is this from the Application > > >>Layer down to the _transport layer_ (if you cared to look at > > >>_any_ LL transport). > > Not all HBA drivers implement a mapping to a SCSI transport, we have > raid drivers and even an FC driver that has its own lun definition that > does not fit any SAM or SCSI spec. May I ask you to name those drivers/HBAs, it would be interesting to look at how REPORT_LUN results are interpreted there. Actually, the data from the REPORT_LUN response is always treated as proper 8 byte LUN and it is converted to int by scsilun_to_int(). What is interesting is how those derivers/HBA treat integer "lun" in queuecommand or EH calls. > I think the only HBA's today that can handle an 8 byte lun are lpfc and > iscsi (plus new SAS ones). I am not aware of any SCSI/FC/SAS/etc hardware which uses more then just first two bytes, but all drivers I looked at to proper bytes rearrangement for those two bytes, and, as a result they do support 00b and 01b addressing modes. > So, we can't have one "LUN" that fits all, and it makes no sense to call > it a LUN when it is really a wtf. IMHO one 8 byte LUN is better then wtf. I's kinda obvious :) Sergey Panov ======================================================================== Any opinions are personal and not necessarily those of my former, present, or future employers. - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
