Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan
-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- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@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
-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- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@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
-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- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@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
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()? -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@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
-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- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@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
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 h...@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 majord...@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
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]wlunIBM 2107900 .107 - [0:0:0:1085358099]diskIBM 2107900 .107 /dev/sda where the second maps to LUN 401340b1. Again, the initiator _must not_ attempt to decode the LUN. To stick with the above example, LUN 400040b1 and LUN 40b1 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 h...@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 majord...@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
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. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@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
-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- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@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
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. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@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
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 'lun 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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@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
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 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
