SCSI luns

SCSI luns

[Amrut Joshi]

Hi,

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
store this mapping somewhere. This can be simplified by storing it in
scsi_device. This field will be meaningful only if sdev->scsi_level >=
SCSI_3.

Heres the patch
-----------------------------------------------------------------------------------------------------------------
--- drivers/scsi/scsi_scan.c.orig       2005-06-30 04:30:53.000000000 +0530
+++ drivers/scsi/scsi_scan.c    2005-07-12 16:19:48.533788528 +0530
@@ -1170,6 +1170,7 @@
                                       " aborted\n", devname, lun);
                                break;
                        }
+                        memcpy(sdev->lun_address, lunp,
sizeof(sdev->lun_address));
                }
        }

--- include/scsi/scsi_device.h.orig     2005-06-30 04:30:53.000000000 +0530
+++ include/scsi/scsi_device.h  2005-07-12 16:19:48.534788376 +0530
@@ -58,6 +58,8 @@
                                           could all be from the same event. */

        unsigned int id, lun, channel;
+        struct scsi_lun lun_address;    /* scsi address returned by REPORT_LUNS
+                                         * usable only if
sdev->scsi_lun >= SCSI_3 */

        unsigned int manufacturer;      /* Manufacturer of device, for using
                                         * vendor-specific cmd's */

----------------------------------------------------------------------------------------------------------------------

Please CC replies to me as I am not on the list.

Thanks,
-Amrut!

Re: SCSI luns

[Arjan van de Ven]

On Tue, 2005-07-12 at 16:52 +0530, Amrut Joshi wrote:
> Hi,
> 
> 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

which LDD is this? Is it ready for merging into the linux kernel yet?

> store this mapping somewhere. This can be simplified by storing it in
> scsi_device. This field will be meaningful only if sdev->scsi_level >=
> SCSI_3.

> Heres the patch

your patch is whitespace damanged unfortunately... 

> -----------------------------------------------------------------------------------------------------------------
> --- drivers/scsi/scsi_scan.c.orig       2005-06-30 04:30:53.000000000 +0530
> +++ drivers/scsi/scsi_scan.c    2005-07-12 16:19:48.533788528 +0530
> @@ -1170,6 +1170,7 @@
>                                        " aborted\n", devname, lun);
>                                 break;
>                         }
> +                        memcpy(sdev->lun_address, lunp,
> sizeof(sdev->lun_address));
>                 }
>         }
> 
> --- include/scsi/scsi_device.h.orig     2005-06-30 04:30:53.000000000 +0530
> +++ include/scsi/scsi_device.h  2005-07-12 16:19:48.534788376 +0530
> @@ -58,6 +58,8 @@
>                                            could all be from the same event. */
> 
>         unsigned int id, lun, channel;
> +        struct scsi_lun lun_address;    /* scsi address returned by REPORT_LUNS
> +                                         * usable only if
> sdev->scsi_lun >= SCSI_3 */
> 
>         unsigned int manufacturer;      /* Manufacturer of device, for using
>                                          * vendor-specific cmd's */
> 
> ----------------------------------------------------------------------------------------------------------------------
> 
> Please CC replies to me as I am not on the list.
> 
> Thanks,
> -Amrut!
> -
> 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/

Re: SCSI luns

[Amrut Joshi]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

Hi,

On 7/12/05, Arjan van de Ven <arjan@infradead.org> wrote:
> On Tue, 2005-07-12 at 16:52 +0530, Amrut Joshi wrote:
> > Hi,
> >
> > 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
> 
> which LDD is this? Is it ready for merging into the linux kernel yet?
> 

It will be ready for submission in a couple of months. The design (and
implementation) would be simplified if these changes are accepted. Any
thoughts?

Sorry for the garbled patch. Attaching it again. 

Please CC me on the replies.

Thanks,
-Amrut!

[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 821 bytes --]

--- drivers/scsi/scsi_scan.c.orig	2005-06-30 04:30:53.000000000 +0530
+++ drivers/scsi/scsi_scan.c	2005-07-12 16:19:48.533788528 +0530
@@ -1170,6 +1170,7 @@
 				       " aborted\n", devname, lun);
 				break;
 			}
+                        memcpy(sdev->lun_address, lunp, sizeof(sdev->lun_address));
 		}
 	}
 
--- include/scsi/scsi_device.h.orig	2005-06-30 04:30:53.000000000 +0530
+++ include/scsi/scsi_device.h	2005-07-12 16:19:48.534788376 +0530
@@ -58,6 +58,8 @@
 					   could all be from the same event. */
 
 	unsigned int id, lun, channel;
+        struct scsi_lun lun_address;    /* scsi address returned by REPORT_LUNS
+                                         * usable only if sdev->scsi_lun >= SCSI_3 */
 
 	unsigned int manufacturer;	/* Manufacturer of device, for using 
 					 * vendor-specific cmd's */

Re: SCSI luns

[James Bottomley]

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

Re: SCSI luns

[Patrick Mansfield]

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