Subject: Re: 64-bit LUN support
To: None <tech-kern@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 01/07/2005 08:00:22
> If there are a lot of [LUNs] 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 ?)
I don't really know, but I have some guesses.
Clearly no device needs enough LUNs, in the original sense of a
per-target unit namespace, to need 64 bits of count. I have trouble
imagining any that would overrun 16 bits, and few that would overrun 8.
These LUNs are clearly some kind of sparse identifier, not the simple
per-target unit serial number LUNs originally were. I'm thus not sure
that what the scsipi code calls a LUN is really the right abstraction
to represent them; they feel to me more like unique spindle IDs such as
we're going to want for wedges - I wonder if it might be better to
introduce a mapping layer, so that most of the code uses small integers
for LUNs, mapping between them and the 64-bit sparse values early on
input and late on output.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B