Subject: Re: partition bookkeeping
To: Matthew Jacob <email@example.com>
From: Eduardo E. Horvath <firstname.lastname@example.org>
Date: 09/25/1999 09:12:33
On Wed, 22 Sep 1999, Matthew Jacob wrote:
> > But to do somethign like c0d0l0p0, we have to reserve enough space for the
> > maximum values of fields. We IMMEDIATLY run out of room. For instace, the
> > SCSI-3 spec permits 16 bits of LUN per disk. So right off the bat we
> > can't encode all the possible LUN's on ONE disk!
Wrong. SCSI-3 allows up to 64-bits of LUN data.
> Bill- what I meant was that in SCSI-3, with SCC hierarchical luns, you get
> Level 1 16 Bits
> Level 2 16 Bits
> Level 3 16 Bits
> Level 4 16 Bits
> The current 'SCCLUN' Qlogic Fibre Channel F/W implements the first level
> (16 bits). I've tested it for up to 256 luns.
This is a sample implementation for devices that use the heirarchical LUN
format. It would be incorrect to assume any particular device uses this
format without verifying the proper bit is set in the inquiry data. If
that bit is not set then the host device can not make any assumptions
about the format of the LUN identifier itself and it should be treated as
and opaque 64-bit value.
In fact it's probably not a good idea to interpret even heirarchical LUNs,
since there's really no useful information the kernel can glean from it.
However, since just about every device vendor is using it since it's the
only thing described by standards documentation, and few OS kernels can
handle 64-bit values for LUNs, this interpretation is becoming standard
Eduardo Horvath email@example.com
"I need to find a pithy new quote." -- me