Subject: Re: 64-bit LUN support
To: Manuel Bouyer <>
From: Bill Studenmund <>
List: tech-kern
Date: 01/07/2005 10:34:15
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 07, 2005 at 12:11:39PM +0100, Manuel Bouyer wrote:
> On Thu, Jan 06, 2005 at 05:21:36PM -0800, Jonathan Stone wrote:
> >=20
> > [...]
> > >The other part of the question is what to do about devices that don't=
> > >support REPORT_LUNS. I think some sort of fall-back to the old-style "=
> > >=3D20
> > >LUNs" method would be best.


> > Havent thought about the storage issues, tho.
> One question is how much Luns these devices will really have.
> If there are a lot of them we may have issues with the chan_periphtab[]
> has table. Right now it's 16. But if a periph can have hunderd of LUNs
> (and I guess some have, otherwise what would be the purpose of 64bit LUN =
> then we'll have a problem in scsipi_lookup_periph(). chan_periphtab's siz=
e will
> probably have to be adjusted dynamically.

That change will probably be needed. While I think only high-end things=20
would have more upwards of 100 LUNs, I think more than 16 is quite likely.

64-bit LUNs are hierarchical. They consist of 4 16-bit values. "Normal"=20
devices should use no more than the first 16-bit value. The extra space is=
used for passthrough devices like Eduardo was talking about. Each target=20
device gets its own top-level LUN (value in the first 16 bits) value and=20
each of the LUNs it reports gets shifted 16 bits up, and the two are=20

Example: Say there is a device with LUN 0x00e0000000000000 and LUN
0x0088000000000000. Say a bridge device causes that device to show up on=20
another bus and gives the target an ID of 00C1. The two LUNs would then=20
show up as 00C100E000000000 and 00C1008800000000 within the bridge device=
on the new bus.

> There are a few places where we do a 0->chan_nluns loop in scsipi_base.c,
> and some drivers. The purpose it to find either one, or all LUNs of a
> target. Because of this, switching to a per-target periphtab[] list may m=
> sense.

I think a per-target table would be best.

Also, what do we want todo with 64-bit LUNs for autoconfig? :-)

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)