[PATCH] [SCSI] Automatic LUN removal
From: Ewan D. Milne emi...@redhat.com
This patch adds the capability to configure the kernel to
automatically remove LUNs when a rescan of a SCSI target
finds that LUNs that were previously reported are no longer
being reported. This is only done when a target is scanned
using REPORT LUNS, to avoid removing LUNs due to transport
errors (in other words, the target must be accessible).
Signed-off-by: Ewan D. Milne emi...@redhat.com
---
drivers/scsi/Kconfig | 8 +++
drivers/scsi/scsi_scan.c | 54
2 files changed, 62 insertions(+)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 5d1e614..9642c87 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -292,6 +292,14 @@ config SCSI_ENHANCED_UA
primarily useful when storage arrays that can be reconfigured
are attached to the system, otherwise you can say N here.
+config SCSI_AUTOMATIC_LUN_REMOVAL
+ bool Automatic LUN removal
+ depends on SCSI
+ help
+If you want LUNs to be automatically removed when a SCSI target
+is rescanned and the REPORT LUNS result indicates that LUNs are
+no longer present, say Y. Otherwise, say N.
+
menu SCSI Transports
depends on SCSI
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 1bbbc43..a0d0d97 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -1318,6 +1318,11 @@ static int scsi_report_lun_scan(struct scsi_target
*starget, int bflags,
struct scsi_device *sdev;
struct Scsi_Host *shost = dev_to_shost(starget-dev);
int ret = 0;
+#ifdef CONFIG_SCSI_AUTOMATIC_LUN_REMOVAL
+ unsigned long flags;
+ struct scsi_device *sdev_i;
+ bool found;
+#endif
/*
* Only support SCSI-3 and up devices if BLIST_NOREPORTLUN is not set.
@@ -1490,6 +1495,55 @@ static int scsi_report_lun_scan(struct scsi_target
*starget, int bflags,
}
}
+#ifdef CONFIG_SCSI_AUTOMATIC_LUN_REMOVAL
+ /*
+* See if all of the LUNs that we know about on the target are
+* still being reported in the REPORT LUNS data. If any are not,
+* they have been removed from the target. Remove those LUNs.
+*
+* We only do this for REPORT LUNS scanning, because we do not
+* want to remove LUNs if they are inaccessible due to a transport
+* error. Here, the target has responded to a command.
+*/
+restart:
+ spin_lock_irqsave(shost-host_lock, flags);
+ list_for_each_entry(sdev_i, starget-devices, same_target_siblings) {
+ /*
+* Don't remove the sdev used for the REPORT LUNS command here.
+* It will be removed at the end of the function if necessary.
+*/
+ if (sdev_i == sdev)
+ continue;
+ if (sdev_i-sdev_state == SDEV_DEL)
+ continue;
+ found = 0;
+ for (lunp = lun_data[1]; lunp = lun_data[num_luns]; lunp++) {
+ lun = scsilun_to_int(lunp);
+ if (memcmp(lunp-scsi_lun[sizeof(lun)], \0\0\0\0, 4))
+ continue;
+ else if (lun sdev-host-max_lun)
+ continue;
+ else if (lun == sdev_i-lun) {
+ found = 1;
+ break;
+ }
+ }
+ if (!found) {
+ spin_unlock_irqrestore(shost-host_lock, flags);
+ sdev_printk(KERN_INFO, sdev_i,
+ LUN %d is no longer present, removing\n,
+ sdev_i-lun);
+ __scsi_remove_device(sdev_i);
+ /*
+* Once the device has been removed, the iterator
+* is no longer valid and we have to start again.
+*/
+ goto restart;
+ }
+ }
+ spin_unlock_irqrestore(shost-host_lock, flags);
+#endif
+
out_err:
kfree(lun_data);
out:
--
1.7.11.7
--
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
[PATCH] [SCSI] scsi_debug: Do not respond to INQUIRY commands with CHECK CONDITION when sense pending
From: Ewan D. Milne emi...@redhat.com
According to SPC, INQUIRY commands are not supposed to respond
with a CHECK CONDITION due to a pending UNIT ATTENTION. This
was causing failures when re-scanning a scsi_debug target.
Signed-off-by: Ewan D. Milne emi...@redhat.com
---
drivers/scsi/scsi_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 8a6bf31..68f13be 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -4060,7 +4060,7 @@ write:
errsts = check_condition_result;
break;
}
- if (!errsts devip-sense_pending) {
+ if (!errsts devip-sense_pending (*cmd != INQUIRY)) {
devip-sense_pending = 0;
errsts = check_condition_result;
}
--
1.7.11.7
--
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
[PATCH] [SCSI] sd: Do not return success from init_sd if DIF mempool allocation fails
From: Ewan D. Milne emi...@redhat.com
init_sd() was returning 0 if sd_cdb_cache or sd_cdb_pool could
not be allocated. Return -ENOMEM instead, since the sd_disk_class
and the blkdevs will be unregistered if this happens.
Signed-off-by: Ewan D. Milne emi...@redhat.com
---
drivers/scsi/sd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 8551f3e..4943a4f 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2931,12 +2931,14 @@ static int __init init_sd(void)
0, 0, NULL);
if (!sd_cdb_cache) {
printk(KERN_ERR sd: can't init extended cdb cache\n);
+ err = -ENOMEM;
goto err_out_class;
}
sd_cdb_pool = mempool_create_slab_pool(SD_MEMPOOL_SIZE, sd_cdb_cache);
if (!sd_cdb_pool) {
printk(KERN_ERR sd: can't init extended cdb pool\n);
+ err = -ENOMEM;
goto err_out_cache;
}
--
1.7.11.7
--
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] Use a more selective error recovery strategy based on device capabilities
On 2/13/2013 8:43 PM, Michael Christie wrote: For the case where report supported TMFs is not supported can we just have the LLD return some new return code from the eh callback when it gets FUNCTION_REJECTED. scsi-ml would then clear the eh_*_ok bit, so at least it would not be called again.. Hmm, that seems like a good idea. The question is, does propagating the flag change to all the devices on the I_T make sense? -- 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] scsi_debug: Do not respond to INQUIRY commands with CHECK CONDITION when sense pending
On 13-02-14 11:36 AM, Ewan D. Milne wrote:
From: Ewan D. Milne emi...@redhat.com
According to SPC, INQUIRY commands are not supposed to respond
with a CHECK CONDITION due to a pending UNIT ATTENTION. This
was causing failures when re-scanning a scsi_debug target.
Good pick up. Reference: sam5r12.pdf section 5.14 on
Unit Attentions. And please add REPORT LUNS to your patch.
Doug Gilbert
Signed-off-by: Ewan D. Milne emi...@redhat.com
---
drivers/scsi/scsi_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 8a6bf31..68f13be 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -4060,7 +4060,7 @@ write:
errsts = check_condition_result;
break;
}
- if (!errsts devip-sense_pending) {
+ if (!errsts devip-sense_pending (*cmd != INQUIRY)) {
devip-sense_pending = 0;
errsts = check_condition_result;
}
--
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] Use a more selective error recovery strategy based on device capabilities
Each logical unit is independent and is allowed to be different. Examples: In a RAID controller, the direct-access block device type logical units (i.e., logical drives) are probably all the same, but storage array controller and enclosure service type logical units might be more limited. In a tape library, sequential-access device type logical units (i.e., tape drives) might differ from a media changer logical unit. Although the SCSI transport protocol might currently mandate everything and leave no options, that might change in the next version of the SCSI transport protocol. -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- ow...@vger.kernel.org] On Behalf Of Jeremy Linton Sent: Thursday, 14 February, 2013 2:57 PM To: Michael Christie Cc: Hannes Reinecke; Linux Scsi; Elliott, Robert (Server Storage) Subject: Re: [PATCH] Use a more selective error recovery strategy based on device capabilities On 2/13/2013 8:43 PM, Michael Christie wrote: For the case where report supported TMFs is not supported can we just have the LLD return some new return code from the eh callback when it gets FUNCTION_REJECTED. scsi-ml would then clear the eh_*_ok bit, so at least it would not be called again.. Hmm, that seems like a good idea. The question is, does propagating the flag change to all the devices on the I_T make sense? -- 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 -- 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] Use a more selective error recovery strategy based on device capabilities
On 02/14/2013 09:57 PM, Jeremy Linton wrote: On 2/13/2013 8:43 PM, Michael Christie wrote: For the case where report supported TMFs is not supported can we just have the LLD return some new return code from the eh callback when it gets FUNCTION_REJECTED. scsi-ml would then clear the eh_*_ok bit, so at least it would not be called again.. Hmm, that seems like a good idea. The question is, does propagating the flag change to all the devices on the I_T make sense? Hmm. Again, I've yet to find a storage array which actually _does_ reject a TMF. None of mine do, not even the latest and greatest NetApp Ontap version ... 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
