SCSI luns

PATCH Amrut Joshi 4 participants 5 messages Jul 12, 2005 – Jul 15, 2005 SCSI

Share & tools

Amrut Joshi

author

2005-07-12 11:24 UTC #0 lore raw

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
-----------------------------------------------------------------------------------------------------------------

scsi/scsi_scan.c 2005-07-12 16:19:48.533788528 +0530 renamed from scsi/scsi_scan.c.orig 2005-06-30 04:30:53.000000000 +0530 +1 -0

@@ -1170,6 +1170,7 @@
                                       " aborted\n", devname, lun);
                                break;
                        }
+                        memcpy(sdev->lun_address, lunp,

sizeof(sdev->lun_address));
                }
        }

scsi/scsi_device.h 2005-07-12 16:19:48.534788376 +0530 renamed from scsi/scsi_device.h.orig 2005-06-30 04:30:53.000000000 +0530 +2 -0

@@ -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!

Arjan van de Ven

2005-07-12 11:38 UTC #1 lore raw

Quoted 6 lines · 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

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

Quoted 5 lines

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...

Quoted 36 lines

-----------------------------------------------------------------------------------------------------------------
scsi/scsi_scan.c 2005-07-12 16:19:48.533788528 +0530 renamed from scsi/scsi_scan.c.orig 2005-06-30 04:30:53.000000000 +0530 +1 -0
@@ -1170,6 +1170,7 @@
                                       " aborted\n", devname, lun);
                                break;
                        }
+                        memcpy(sdev->lun_address, lunp,
 sizeof(sdev->lun_address));
                }
        }
scsi/scsi_device.h 2005-07-12 16:19:48.534788376 +0530 renamed from scsi/scsi_device.h.orig 2005-06-30 04:30:53.000000000 +0530 +2 -0
@@ -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,
scsi/scsi_device.h 2005-07-12 16:19:48.534788376 +0530 renamed from scsi/scsi_device.h.orig 2005-06-30 04:30:53.000000000 +0530 +0 -2
-Amrut!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Amrut Joshi

author

2005-07-12 11:56 UTC #2 lore raw

Hi,

Quoted 10 lines · Arjan van de Ven

Quoted 6 lines · 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
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!

James Bottomley

2005-07-12 16:17 UTC #3 lore raw

In reply to Arjan van de Ven

Thanks for redirecting to the correct list.

Quoted 5 lines · Arjan van de Ven

Quoted 4 lines · Amrut Joshi
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

Patrick Mansfield

2005-07-15 18:00 UTC #4 lore raw

Quoted 13 lines · James Bottomley

Thanks for redirecting to the correct list.
Quoted 5 lines · Arjan van de Ven
Quoted 4 lines · Amrut Joshi
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).

Quoted 8 lines

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