Subject: Re: 64-bit LUN support
To: Eduardo Horvath <eeh@NetBSD.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 01/07/2005 11:29:39
--gr/z0/N6AeWAPJVB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 07, 2005 at 06:45:31PM +0000, Eduardo Horvath wrote:
> On Fri, Jan 07, 2005 at 10:34:15AM -0800, Bill Studenmund wrote:
>=20
> > 64-bit LUNs are hierarchical. They consist of 4 16-bit values. "Normal"=
=20
>=20
> Don't count on it. LUN format is application dependent. There are
> at least two example implementations in the standards documetnation
> which use the bits quite differently. And I'm aware of some others.
Well, the mapping I describe of changing LUNs at passthrough is right out=
=20
of SAM2 & SAM3. And its main point is to explain why we'd want 64-bit=20
LUNs.
> Unless you can be sure that a device uses a particular LUN format
> it's best to consider them to be opaque cookies. LUN values can
> change as a device changes state or is reconfigured (ISTR there's
> a unit attention condition associated w/that).
I agree we should consider them opaque.=20
Take care,
Bill
--gr/z0/N6AeWAPJVB
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFB3uMjWz+3JHUci9cRAmo2AJ9chytTJkJLA4lewnWOmmYQ9Y2RZgCeKVG8
KcMw8nux7kYFlKmEpwjv+20=
=sR+O
-----END PGP SIGNATURE-----
--gr/z0/N6AeWAPJVB--