Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)

[Sergey Panov <sipan@sipan.org>]

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.