Re: SCSI luns

[Patrick Mansfield <patmans@us.ibm.com>]

On Tue, Jul 12, 2005 at 12:17:53PM -0400, James Bottomley wrote:
> Thanks for redirecting to the correct list.
> 
> On Tue, 2005-07-12 at 13:38 +0200, Arjan van de Ven wrote:
> > On Tue, 2005-07-12 at 16:52 +0530, Amrut Joshi wrote:
> > > Currently linux scsi subsystem doesnt store the 8-byte luns which are
> > > recieved in REPORT_LUNS reply. This information is forver lost once
> > > the scan is over. In my LDD  I need this information. Currently I have
> > > to snoop REPORT_LUNS reply, do scsilun_to_int for all the luns and
> 
> Our current transformation routine scsilun_to_int is bijective as long
> as the original scsi_lun doesn't overrun 32 bits (which it might well do
> one day).
> 
> Why can't you simply do this by transforming back the lun?
> 
> In general, I'm not in favour of adding redundant information to the
> device structure, so if you can demonstrate we overrun our allotted 32
> bits, the solution is probably to take lun up to u64 and still do the
> back transform (the alternative being to substitute lun with it's
> structural equivalen which would entail a lot of pain throught the SCSI
> subsytem).

James -

There have been cases of going past 32 bits, though I have not seen
specifics, storage devices are instead being configured to avoid the
problem.

Using some of those configurations has bad consequences. For example, one
storage box enumerates the LUN numbering, but this means existing LUN
values can change when a new LU is added (ugh)!

Trying to have a compatible 64 bit LUN for all uses (change the current
lun to u64) looks hard, given all of the odd mappings, having to deal with
the high bits being set (for non-zero LU address methods), and trying to
figure out whether the 64 bit LUN can fit into 32 bits (really about 8
bits for SPI, and 16 bits for some HBA's).

Or by "back transform" did you mean change lun to u64, and conditionally
map to 32 bits for drivers (currently all) that don't support a 64 bit
LUN? Hmmmm ...

Printing the lun value for messages is odd/painful no matter how it is
added, since for example, 64 bit value for LUN 1 is something like 0001
0000 0000 0000. Having both 32 and 64 bit versions makes it even odder. An
sdev_printk() makes this easier, as we would have to print to
conditionally print lun in both formats (old and new) depending on HBA
support.

But just adding a 64 bit LUN in parallel does not help much if the scan
code is not modified (we'll fail to scan LUNs with higher bits set).

-- Patrick Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/