Subject: Re: 64-bit LUN support
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 01/07/2005 10:34:15
--SLDf9lqlvOQaIe6s
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=
=3D20
> > >support REPORT_LUNS. I think some sort of fall-back to the old-style "=
max=3D
> > >=3D20
> > >LUNs" method would be best.

[snip]

> > Havent thought about the storage issues, tho.
>=20
> 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=
=20
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
combined.

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=
=20
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=
ake
> sense.

I think a per-target table would be best.

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

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFB3tYnWz+3JHUci9cRAkb1AJkBZheiwOTB48MlZTXfcsNFa2HX8wCfVDxg
euYr5/lN2M0H2DvggOFiewU=
=BDgv
-----END PGP SIGNATURE-----

--SLDf9lqlvOQaIe6s--