On Mon, Sep 12, 2005 at 12:21:20PM -0500, James Bottomley wrote:
> On Mon, 2005-09-12 at 09:45 -0700, Patrick Mansfield wrote:
> > On Mon, Sep 12, 2005 at 09:57:21AM -0500, James Bottomley wrote:
> > > be free to increase it if necessary. Note: you do actually need either
> > > an array with more than two levels of nesting actually to need the
> > > increase and no-one actually seems to have one of these yet.
> >
> > That is not correct, I posted before on this, the address method is in the
> > high bits of the 8 byte LUN and tells how to "interpret" the LUN value.
> > You can't convert from an int to 8 byte LUN (without any other
> > information) and set these bits. See SAM-4 in (or near) section 4.9.7.
> >
> > So some storage devices that want to use addressing methods other than 00b
> > don't because we do not have 8 byte LUN support in linux, and then we have
> > other problems because of this.
>
> Well, as long as we represent the u32 (or u64) as
>
> scsilun[1] | (scsilun[0] << 8) | (scsilun[3] << 16) | (scsilun[2] << 24)
>
> I think we cover all 2 level lun bases, don't we (obviously we ignore
> levels 3 and 4 [and 6 and 8 byte extended luns])?
hmmm ... yes, I'm wrong, it works (or should) in the existing code.
I don't know what I was thinking.
Though we still have problems with scsi_report_lun_scan code like:
} else if (lun > sdev->host->max_lun) {
max_lun just has to be large, at least greater than 0xc001 (49153), maybe
even 0xffffffff, correct?
But then some sequential scanning could take a while. Maybe the above
check is not needed.
lpfc has max_luns set to 256, with max limited to 32768, I don't know how
it could be working OK here. (Has James S or anyone tested this?)
Probably similar for qlogic and maybe other non-SPI transports (though
current qlogic max_luns is 65535, gets us to ff ff 00 00 00 00 00 00).
> That representation works transparently for type 00b which is what SPI
> and other legacy expects, since our lun variable is equal to the actual
> numeric lun. Although SAM allows type 01b for arrays with < 256 LUNs it
> does strongly suggest you use type 00b which hopefully will cover us for
> a while longer...
>
> fc already uses int_to_scsilun and 8 byte LUN addressing, so it will
> work even in the 01b case (the numbers that the mid-layer prints will
> look odd, but at least the driver will work).
OK.
-- Patrick Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |