[PATCH] scsi: Allow 64-bit LUNs during report lun scan

[PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Hannes Reinecke]

shost->max_lun is only ever useful when doing a sequential
scan as we need to limit the number of devices to scan there.
For report lun scan we should allow _any_ reported LUN number
as long as the LLDD supports 64 bit LUNs.

So add a new flag 'support_64bit_luns' to the scsi host and
modify report lun scan to not check for max_luns during
scanning if that flag is set. This will get rid of the
annoying 'lunXXXX has a LUN larger than allowed ...'
message and allow scanning to continue.

Cc: James Bottomley <jbottomley@parallels.com>
Cc: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: James Smart <james.smart@emulex.com>
Cc: Andrew Vasquez <andrew.vasquez@qlogic.com>
Cc: Krishna Gudipati <kgudipat@brocade.com>
Cc: Jayamohan Kallickal <jayamohan.kallickal@emulex.com>
Cc: Abhijeet Joglekar <abjoglek@cisco.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>

diff --git a/drivers/s390/scsi/zfcp_scsi.c b/drivers/s390/scsi/zfcp_scsi.c
index 7b31e3f..375d69f 100644
--- a/drivers/s390/scsi/zfcp_scsi.c
+++ b/drivers/s390/scsi/zfcp_scsi.c
@@ -316,6 +316,7 @@ static struct scsi_host_template zfcp_scsi_host_template = {
 	.dma_boundary		 = ZFCP_QDIO_SBALE_LEN - 1,
 	.cmd_per_lun		 = 1,
 	.use_clustering		 = 1,
+	.support_64bit_luns	 = 1,
 	.shost_attrs		 = zfcp_sysfs_shost_attrs,
 	.sdev_attrs		 = zfcp_sysfs_sdev_attrs,
 };
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 4e2733d..8ad5e50 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -543,6 +543,7 @@ static struct scsi_host_template beiscsi_sht = {
 	.max_sectors = BEISCSI_MAX_SECTORS,
 	.cmd_per_lun = BEISCSI_CMD_PER_LUN,
 	.use_clustering = ENABLE_CLUSTERING,
+	.support_64bit_luns = 1,
 	.vendor_id = SCSI_NL_VID_TYPE_PCI | BE_VENDOR_ID,
 
 };
diff --git a/drivers/scsi/bfa/bfad_im.c b/drivers/scsi/bfa/bfad_im.c
index 8f92732..410af66 100644
--- a/drivers/scsi/bfa/bfad_im.c
+++ b/drivers/scsi/bfa/bfad_im.c
@@ -803,6 +803,7 @@ struct scsi_host_template bfad_im_scsi_host_template = {
 	.sg_tablesize = BFAD_IO_MAX_SGE,
 	.cmd_per_lun = 3,
 	.use_clustering = ENABLE_CLUSTERING,
+	.support_64bit_luns = 1,
 	.shost_attrs = bfad_im_host_attrs,
 	.max_sectors = BFAD_MAX_SECTORS,
 	.vendor_id = BFA_PCI_VENDOR_ID_BROCADE,
@@ -825,6 +826,7 @@ struct scsi_host_template bfad_im_vport_template = {
 	.sg_tablesize = BFAD_IO_MAX_SGE,
 	.cmd_per_lun = 3,
 	.use_clustering = ENABLE_CLUSTERING,
+	.support_64bit_luns = 1,
 	.shost_attrs = bfad_im_vport_attrs,
 	.max_sectors = BFAD_MAX_SECTORS,
 };
diff --git a/drivers/scsi/fnic/fnic_main.c b/drivers/scsi/fnic/fnic_main.c
index fbf3ac6..c636cf2 100644
--- a/drivers/scsi/fnic/fnic_main.c
+++ b/drivers/scsi/fnic/fnic_main.c
@@ -102,6 +102,7 @@ static struct scsi_host_template fnic_host_template = {
 	.change_queue_type = fc_change_queue_type,
 	.this_id = -1,
 	.cmd_per_lun = 3,
+	.support_64bit_luns = 1,
 	.can_queue = FNIC_MAX_IO_REQ,
 	.use_clustering = ENABLE_CLUSTERING,
 	.sg_tablesize = FNIC_MAX_SG_DESC_CNT,
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 1d7da3f..39c714c 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -6014,6 +6014,7 @@ static struct scsi_host_template driver_template = {
 	.max_sectors = IPR_IOA_MAX_SECTORS,
 	.cmd_per_lun = IPR_MAX_CMD_PER_LUN,
 	.use_clustering = ENABLE_CLUSTERING,
+	.support_64bit_luns = 1,
 	.shost_attrs = ipr_ioa_attrs,
 	.sdev_attrs = ipr_dev_attrs,
 	.proc_name = IPR_NAME
diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
index 60e5a17..d7de766 100644
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -5146,6 +5146,7 @@ struct scsi_host_template lpfc_template = {
 	.sg_tablesize		= LPFC_DEFAULT_SG_SEG_CNT,
 	.cmd_per_lun		= LPFC_CMD_PER_LUN,
 	.use_clustering		= ENABLE_CLUSTERING,
+	.support_64bit_luns	= 1,
 	.shost_attrs		= lpfc_hba_attrs,
 	.max_sectors		= 0xFFFF,
 	.vendor_id		= LPFC_NL_VENDOR_ID,
@@ -5169,6 +5170,7 @@ struct scsi_host_template lpfc_vport_template = {
 	.sg_tablesize		= LPFC_DEFAULT_SG_SEG_CNT,
 	.cmd_per_lun		= LPFC_CMD_PER_LUN,
 	.use_clustering		= ENABLE_CLUSTERING,
+	.support_64bit_luns	= 1,
 	.shost_attrs		= lpfc_vport_attrs,
 	.max_sectors		= 0xFFFF,
 	.change_queue_depth	= lpfc_change_queue_depth,
diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index ce90d05..09229c4 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -67,6 +67,7 @@ static struct scsi_host_template mvs_sht = {
 	.bios_param		= sas_bios_param,
 	.can_queue		= 1,
 	.cmd_per_lun		= 1,
+	.support_64bit_luns	= 1,
 	.this_id		= -1,
 	.sg_tablesize		= SG_ALL,
 	.max_sectors		= SCSI_DEFAULT_MAX_SECTORS,
diff --git a/drivers/scsi/pm8001/pm8001_init.c b/drivers/scsi/pm8001/pm8001_init.c
index 4c9fe73..39ca498 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -73,6 +73,7 @@ static struct scsi_host_template pm8001_sht = {
 	.sg_tablesize		= SG_ALL,
 	.max_sectors		= SCSI_DEFAULT_MAX_SECTORS,
 	.use_clustering		= ENABLE_CLUSTERING,
+	.support_64bit_luns	= 1,
 	.eh_device_reset_handler = sas_eh_device_reset_handler,
 	.eh_bus_reset_handler	= sas_eh_bus_reset_handler,
 	.target_destroy		= sas_target_destroy,
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index b46f5e9..037adbf 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4330,6 +4330,7 @@ static struct scsi_host_template pmcraid_host_template = {
 	.max_sectors = PMCRAID_IOA_MAX_SECTORS,
 	.cmd_per_lun = PMCRAID_MAX_CMD_PER_LUN,
 	.use_clustering = ENABLE_CLUSTERING,
+	.support_64bit_luns = 1,
 	.shost_attrs = pmcraid_host_attrs,
 	.proc_name = PMCRAID_DRIVER_NAME
 };
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 10d23f8..35bab2f 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -261,6 +261,7 @@ struct scsi_host_template qla2xxx_driver_template = {
 	.cmd_per_lun		= 3,
 	.use_clustering		= ENABLE_CLUSTERING,
 	.sg_tablesize		= SG_ALL,
+	.support_64bit_luns	= 1,
 
 	.max_sectors		= 0xFFFF,
 	.shost_attrs		= qla2x00_host_attrs,
diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index 4cec123..c6d9f38 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -190,6 +190,7 @@ static struct scsi_host_template qla4xxx_driver_template = {
 	.cmd_per_lun		= 3,
 	.use_clustering		= ENABLE_CLUSTERING,
 	.sg_tablesize		= SG_ALL,
+	.support_64bit_luns	= 1,
 
 	.max_sectors		= 0xFFFF,
 	.shost_attrs		= qla4xxx_host_attrs,
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 3e58b22..bebaddf 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -1468,7 +1468,8 @@ static int scsi_report_lun_scan(struct scsi_target *starget, int bflags,
 			for (i = 0; i < sizeof(struct scsi_lun); i++)
 				printk("%02x", data[i]);
 			printk(" has a LUN larger than currently supported.\n");
-		} else if (lun > sdev->host->max_lun) {
+		} else if (!sdev->host->hostt->support_64bit_luns &&
+			   lun > sdev->host->max_lun) {
 			printk(KERN_WARNING "scsi: %s lun%d has a LUN larger"
 			       " than allowed by the host adapter\n",
 			       devname, lun);
diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c
index 3bfaa66..c85d7a0 100644
--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -911,6 +911,7 @@ static struct scsi_host_template pvscsi_template = {
 	.dma_boundary			= UINT_MAX,
 	.max_sectors			= 0xffff,
 	.use_clustering			= ENABLE_CLUSTERING,
+	.support_64bit_luns		= 1,
 	.eh_abort_handler		= pvscsi_abort,
 	.eh_device_reset_handler	= pvscsi_device_reset,
 	.eh_bus_reset_handler		= pvscsi_bus_reset,
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index 4908480..afcf8a7 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -474,6 +474,11 @@ struct scsi_host_template {
 	unsigned ordered_tag:1;
 
 	/*
+	 * True if the low-level driver supports 64-bit LUNs
+	 */
+	unsigned support_64bit_luns:1;
+
+	/*
 	 * Countdown for host blocking with no commands outstanding.
 	 */
 	unsigned int max_host_blocked;

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Jeremy Linton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/13/2013 9:06 AM, Hannes Reinecke wrote:
> So add a new flag 'support_64bit_luns' to the scsi host and modify report
> lun scan to not check for max_luns during scanning if that flag is set.
> This will get rid of the

	Along these lines, I don't think the scsilun_to_int() and int_to_scsilun()
routines are correct for > 2^14  luns. SAM  4.6 defines bits 6,7 of byte zero
in the LU representation format as the address method. Which when set to 00b
limits it to 256 luns but the overflow into the bus ID probably works for some
devices.

	Those routines should probably select/detect an alternative address method
for luns > 256.

	Or am I missing something?







	




	
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRG+8LAAoJEL5i86xrzcy7SL4H/0vZvSuIVH+6yeN62XkKVzok
HBP9Wg9spmOX8ANgJp3KZnOuHSLpVXZTvRRbWpI57sX3UJRZ55nOeA8g75s1hWSp
yOrTQZZodD6/uA6QOdVQgqRCrpZ/jKuARHHlZzULnDRV4/eSrLCpU6CRHFviHxLE
SkgAAJtQwXMRn3PM8QuzzdJ68tIvVZTW/8r795wV0NxI+AlCM51s/PoPWZxq5tNK
tiYbTcRHdh14N4jC6or/hT1r8VdkWEKLhSMLRBVu1wmVIxrdFtoyOqR4CEGwq2vt
HaL9L8Te4bmmxN20/Bu593KUymMMndvFDm9OGEuZzcjXdEJp3pauXO8fyhwJrFw=
=E2w/
-----END PGP SIGNATURE-----

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Bart Van Assche]

On 02/13/13 20:52, Jeremy Linton wrote:
> On 2/13/2013 9:06 AM, Hannes Reinecke wrote:
>> So add a new flag 'support_64bit_luns' to the scsi host and modify report
>> lun scan to not check for max_luns during scanning if that flag is set.
>> This will get rid of the
>
> 	Along these lines, I don't think the scsilun_to_int() and int_to_scsilun()
> routines are correct for > 2^14  luns. SAM  4.6 defines bits 6,7 of byte zero
> in the LU representation format as the address method. Which when set to 00b
> limits it to 256 luns but the overflow into the bus ID probably works for some
> devices.
>
> 	Those routines should probably select/detect an alternative address method
> for luns > 256.
>
> 	Or am I missing something?

I think the LUN-to-int translation should depend on the LUN addressing 
method supported by the target. SAM-5 defines the following LUN 
addressing methods:
a) peripheral device addressing method;
b) flat space addressing method;
c) logical unit addressing method,
d) extended logical unit addressing method;
e) long extended logical unit addressing method.

scsilun_to_int() does the translation correctly for some of these 
addressing methods but not for all of them.

Bart.

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[James Bottomley]

On Wed, 2013-02-13 at 16:06 +0100, Hannes Reinecke wrote:
> shost->max_lun is only ever useful when doing a sequential
> scan as we need to limit the number of devices to scan there.
> For report lun scan we should allow _any_ reported LUN number
> as long as the LLDD supports 64 bit LUNs.
> 
> So add a new flag 'support_64bit_luns' to the scsi host and
> modify report lun scan to not check for max_luns during
> scanning if that flag is set. This will get rid of the
> annoying 'lunXXXX has a LUN larger than allowed ...'
> message and allow scanning to continue.

What advantage does this have over setting max_lun to ~0?

Plus, if we're going to advertise 64 bit lun support I'd rather have us
be actually capable of it ... luns are handled as 32 bit numbers in the
mid layer currently.

James

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[James Bottomley]

On Wed, 2013-02-13 at 13:52 -0600, Jeremy Linton wrote:
> On 2/13/2013 9:06 AM, Hannes Reinecke wrote:
> > So add a new flag 'support_64bit_luns' to the scsi host and modify report
> > lun scan to not check for max_luns during scanning if that flag is set.
> > This will get rid of the
> 
> 	Along these lines, I don't think the scsilun_to_int() and int_to_scsilun()
> routines are correct for > 2^14  luns. SAM  4.6 defines bits 6,7 of byte zero
> in the LU representation format as the address method. Which when set to 00b
> limits it to 256 luns but the overflow into the bus ID probably works for some
> devices.
> 
> 	Those routines should probably select/detect an alternative address method
> for luns > 256.
> 
> 	Or am I missing something?

Yes.  The two functions are simple transforms ensuring that we can pack
up to two levels of luns into a u32 whatever address method is used.  At
the time it was done, no array or other extant system went beyond this.

At the end of the day, a LUN is just a handle, so even if we go to 64
bits we're still going to be packing the address method into the logical
unit "number".

James


James

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Jeremy Linton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/13/2013 9:38 PM, James Bottomley wrote:
> Yes.  The two functions are simple transforms ensuring that we can pack up
> to two levels of luns into a u32 whatever address method is used.  At the
> time it was done, no array or other extant system went beyond this.
> 
> At the end of the day, a LUN is just a handle, so even if we go to 64 bits
> we're still going to be packing the address method into the logical unit
> "number".

	Ok, I will buy that (probably violates SAM5, 4.7.1, but no big deal), two
points.

	First this requires basically every adapter capable of recieving address
method!=0 LUNs to set the 64-bit capable flag that is included in this patch.
Otherwise the "scsi: %s lun%d has a LUN larger than allowed by the host
adapter\n" path fires even for a small number of luns because the address
method bit creates a "lun" > max_luns in all cases.



	Second, its possible with address method 11b, that none of the devices are
actually visible even with this patch, as a device that chooses to use address
method=11b and one of the >16 bit addressing methods gets its LSB truncated by
the 32-bit return from scsilun_to_int(). Not that I have see one of those, no
one needs that many LUNs <chuckle>. So, the flag in this patch is somewhat
misnamed as it doesn't really support 64-bit luns. To stick to the existing
method scsilun_to_int needs to be u64.


	BTW: Tiny syntax cleanup, scsilun_to_int() should have a return type of
unsigned.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRHSa0AAoJEL5i86xrzcy7K6oH/RBnWrpDJGt+mcvR8of6BM6y
nwtokc/GCas/RFcn1rxvayicKcqAgYGeE7PRoECvIiDoSNFacNGCvf3XQye4tF2y
IMfGZhKlndJWKUppv5ELgyzpEbh49U3XK/Vq7O2B6pB46O6Iiqz1PUWK+yZF757B
O1Q+w49FUSbq3AsPxYh4CeHj7+L+6o6mAILzl8lTgGGRkhQFr15jR1K29AUhMyyM
xCTeWw++N9Iu5ENjIdiBk0E5bQZujKBBrSpuqWnyqPzhGX74AYexkOkEiXGlEBO7
Vr31C6TBVdpOvVdXlGoR/+ZcUxju1Q9ozmdW0QEzGMvNDbax3sS0/7wSZy9bKb4=
=j5FP
-----END PGP SIGNATURE-----

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Jeremy Linton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/13/2013 9:37 PM, James Bottomley wrote:

> What advantage does this have over setting max_lun to ~0?

	Is it possible the adapters have LUN resource limits as well as ID limits? In
those cases it would be nice to notify the user that LUNs exist, but are not
addressable with the given hba. Of course ignoring the address mode bits keeps
this from working properly as the max_lun needs to be set much larger than the
actual supported lun limit.




	


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRHVVKAAoJEL5i86xrzcy7zCQIAJzMmQbVb6yFDEv3od16xVI3
DN8ZzscwJQcreJfIpyoBPk4d0gjfCXO1Cc/PeMQegNwgc4TmfoLHXj1/61irATjv
GH+xGiJCMxcLX1eIF5D3JC8cleXa+A1YD5ayKeIkYsHSK4S5kPovmS5gzvgJlhPE
N5oToRe5RQda0nAeiV0VMPKuxANud2ZC6N61ncMHAn1wLeI7gq2JBtvZi3NXAfub
IRacak9LN9QLrlrZh6YQdA8RK9LVGHJwCYahBUG1MYH0ceTyoj15BOPLT/El3ET5
6CSpi7a/TMufwpWtLJp4YzVUU2tIvFxIusTbrzMy0ioYSWD9J7Egangs5ue48Xg=
=yyk0
-----END PGP SIGNATURE-----

RE: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Elliott, Robert (Server Storage)]

Like James notes, LUNs should generally be treated as opaque values.

For example, these are all unique LUNs:
- address method 00b, bus identifier=00_0000b, target or LUN=nnh
- address method 01b, flat space LUN={00b, 0nnh}
- address method 11b, length=01b, extended address method=2h, extended flat space LUN=0000nnh
- address method 11b, length=10b, extended address method=2h, long extended flat space LUN=000000nnh

They are not four different values that provide access the same logical unit with logical unit number nnh.  The storage device might implement a access control /LUN mapping feature that does something like that, but nothing in the LUN value itself officially implies that they are related.

scsilun_to_int() does not appear to be used very much; I see 35 matches in linux-3.7-rc5. Perhaps the callers should be updated to support 64-bit LUNs and decide what to do if they cannot handle larger values.


> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Jeremy Linton
> Sent: Thursday, 14 February, 2013 12:02 PM
> To: James Bottomley
> Cc: Hannes Reinecke; linux-scsi@vger.kernel.org
> Subject: Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2/13/2013 9:38 PM, James Bottomley wrote:
> > Yes.  The two functions are simple transforms ensuring that we can pack up
> > to two levels of luns into a u32 whatever address method is used.  At the
> > time it was done, no array or other extant system went beyond this.
> >
> > At the end of the day, a LUN is just a handle, so even if we go to 64 bits
> > we're still going to be packing the address method into the logical unit
> > "number".
> 
> 	Ok, I will buy that (probably violates SAM5, 4.7.1, but no big deal), two
> points.
> 
> 	First this requires basically every adapter capable of recieving address
> method!=0 LUNs to set the 64-bit capable flag that is included in this patch.
> Otherwise the "scsi: %s lun%d has a LUN larger than allowed by the host
> adapter\n" path fires even for a small number of luns because the address
> method bit creates a "lun" > max_luns in all cases.
> 
> 
> 
> 	Second, its possible with address method 11b, that none of the devices
> are
> actually visible even with this patch, as a device that chooses to use address
> method=11b and one of the >16 bit addressing methods gets its LSB truncated
> by
> the 32-bit return from scsilun_to_int(). Not that I have see one of those, no
> one needs that many LUNs <chuckle>. So, the flag in this patch is somewhat
> misnamed as it doesn't really support 64-bit luns. To stick to the existing
> method scsilun_to_int needs to be u64.
> 
> 
> 	BTW: Tiny syntax cleanup, scsilun_to_int() should have a return type of
> unsigned.
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJRHSa0AAoJEL5i86xrzcy7K6oH/RBnWrpDJGt+mcvR8of6BM6y
> nwtokc/GCas/RFcn1rxvayicKcqAgYGeE7PRoECvIiDoSNFacNGCvf3XQye4tF2y
> IMfGZhKlndJWKUppv5ELgyzpEbh49U3XK/Vq7O2B6pB46O6Iiqz1PUWK+yZF757B
> O1Q+w49FUSbq3AsPxYh4CeHj7+L+6o6mAILzl8lTgGGRkhQFr15jR1K29AUhMyy
> M
> xCTeWw++N9Iu5ENjIdiBk0E5bQZujKBBrSpuqWnyqPzhGX74AYexkOkEiXGlEBO7
> Vr31C6TBVdpOvVdXlGoR/+ZcUxju1Q9ozmdW0QEzGMvNDbax3sS0/7wSZy9bKb
> 4=
> =j5FP
> -----END PGP SIGNATURE-----
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Jeremy Linton]

On 2/14/2013 4:04 PM, Elliott, Robert (Server Storage) wrote:
> Like James notes, LUNs should generally be treated as opaque values.

	I agree, except there is a max host lun check based on a decoded lun value. Not
really sure why its there other than maybe some of the HBA's have resource
issues with a large number of luns.

> scsilun_to_int() does not appear to be used very much; I see 35 matches in linux-3.7-rc5. Perhaps the callers should be updated to support 64-bit LUNs and decide what to do if they cannot handle larger values.


	Which is a perfectly valid fix, but if that is being done, why do any swizzling
in scsilun_to_int()?

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Jeremy Linton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/14/2013 4:04 PM, Elliott, Robert (Server Storage) wrote:
> Like James notes, LUNs should generally be treated as opaque values.

	Maybe another issue to consider is how they are being displayed in userland.
A device with two luns using one of the alternative lun addressing methods is
going to get some pretty strange looking lun numbers showing up in userspace
if they aren't decoded properly.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRHWjKAAoJEL5i86xrzcy7UuQH/RG5zp3/H5GoVDH+81M/dtHq
RiHjCXuaHpESI6JGem8m7IrhFIRdEEuFL8OoJawMKLsxu6FD9Iwu0A9v99BNqLcc
1Jb+u/AVAhr4W5xB5Oua17IFwIVjxHipYvGDhbzfE/Fvy2lRJy5UDN1GXQMkVtI2
FSYVk3GI51LF2GKbtWtMYb0fTx1jvhlE3WMgeUOyjtNCK7wVOKOPCD8PJkMKC07f
v50APFDLp2zCiVel1w3+QQLT96pcMFcfPalwMcfHjSHRxHyXgHlv5kZIk0pqiDxd
GNvCc4Kalvc5BzDYw0j3s4+tzRUjtPEniJYO/jDC9MF507XlANVZgAILwu5PJbk=
=35DZ
-----END PGP SIGNATURE-----

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Hannes Reinecke]

On 02/14/2013 07:02 PM, Jeremy Linton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/13/2013 9:38 PM, James Bottomley wrote:
>> Yes.  The two functions are simple transforms ensuring that we can pack up
>> to two levels of luns into a u32 whatever address method is used.  At the
>> time it was done, no array or other extant system went beyond this.
>>
>> At the end of the day, a LUN is just a handle, so even if we go to 64 bits
>> we're still going to be packing the address method into the logical unit
>> "number".
>
> 	Ok, I will buy that (probably violates SAM5, 4.7.1, but no big deal), two
> points.
>
> 	First this requires basically every adapter capable of recieving address
> method!=0 LUNs to set the 64-bit capable flag that is included in this patch.
> Otherwise the "scsi: %s lun%d has a LUN larger than allowed by the host
> adapter\n" path fires even for a small number of luns because the address
> method bit creates a "lun" > max_luns in all cases.
>
Hehe. As we're down to nitpicking:
The 'support_64bit_luns' is a _hardware_ flag.
Some HBA hardware (SPI, and most RAID HBAs) simply do not have the 
facilities to _send_ 64bit LUNs; SPI HBAs in most cases simply 
reserve a byte for the LUN.

So irrespective of what response they'll be getting via REPORT_LUNS 
they lack the possibility of addressing all of them.
And for those we need the 'max_luns' setting.

>
>
> 	Second, its possible with address method 11b, that none of the devices are
> actually visible even with this patch, as a device that chooses to use address
> method=11b and one of the >16 bit addressing methods gets its LSB truncated by
> the 32-bit return from scsilun_to_int(). Not that I have see one of those, no
> one needs that many LUNs <chuckle>. So, the flag in this patch is somewhat
> misnamed as it doesn't really support 64-bit luns. To stick to the existing
> method scsilun_to_int needs to be u64.
>
Correct. This I'll be addressing with a later patch, moving 'lun' to 
full 64bit.

>
> 	BTW: Tiny syntax cleanup, scsilun_to_int() should have a return type of
> unsigned.
>
Will be cleaned up with the next round of patches.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Hannes Reinecke]

On 02/14/2013 11:44 PM, Jeremy Linton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/14/2013 4:04 PM, Elliott, Robert (Server Storage) wrote:
>> Like James notes, LUNs should generally be treated as opaque values.
>
> 	Maybe another issue to consider is how they are being displayed in userland.
> A device with two luns using one of the alternative lun addressing methods is
> going to get some pretty strange looking lun numbers showing up in userspace
> if they aren't decoded properly.
>
No. LUNs with anything other than peripheral addressing do look 
weird even nowadays.
Cf IBM DS8000 presents me with LUNs like:

# lsscsi
[0:0:0:49409]wlun    IBM      2107900          .107  -
[0:0:0:1085358099]disk    IBM      2107900          .107  /dev/sda

where the second maps to LUN 401340b100000000.

Again, the initiator _must not_ attempt to decode the LUN.
To stick with the above example, LUN 400040b100000000 and LUN
40b1000000000000 do refer to the same LUN number, albeit on a 
different Level. And it's totally up to the target which physical 
LUN these numbers refer to. The initiator has to map these numbers 
to different devices; to figure out whether the devices are 
identical one would have to look at VPD page 0x83.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Bart Van Assche]

On 02/14/13 23:44, Jeremy Linton wrote:
> On 2/14/2013 4:04 PM, Elliott, Robert (Server Storage) wrote:
>> Like James notes, LUNs should generally be treated as opaque values.
>
> Maybe another issue to consider is how they are being displayed in userland.
> A device with two luns using one of the alternative lun addressing methods is
> going to get some pretty strange looking lun numbers showing up in userspace
> if they aren't decoded properly.

One example of this is the ibmvscsi protocol. Since the ibmvscsi target 
driver uses the LUN addressing method its LUNs show up with LUN numbers 
256  512  768 ... at a Linux SCSI initiator.

Bart.

Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Jeremy Linton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/13/2013 9:37 PM, James Bottomley wrote:

> What advantage does this have over setting max_lun to ~0?


	Actually, after having all those other discussions. I've come to see the
elegance in this suggestion.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRHmFuAAoJEL5i86xrzcy7RXkH+QHeQeWZE4Z5Qe2GcKj64SVV
eqnQNiOoOR4sKmPM1J8AhBbOj/sl6upSSXrHgcK9EGKCA8R099wwdYjFhyLy+RQn
HZURfpJbxEWItGJd9mouGqR6SeUiifs7If9VUp+/OJXiBtePD8Vu3GQB0p7v0DwI
BlKkUTnMAQgYPYPc8iMJiGJYf38ZtMJFU0oHow5L0VZG6zTJhxcOmAxEuu1zqJWX
5hvSw0jgXmAJ/p798LWKw4FjhdBFAyG1BcK8RmEsHqoW4XecSHU6qXvxokiVgIMt
QKMuCHTRjxzVQCkpyUUc3hEH24kZFU8PqeMPw46dFYndZrM9Jg/3zq74k6aZlJo=
=wwUR
-----END PGP SIGNATURE-----