On 08/27/2014 09:31 AM, Hannes Reinecke wrote: > On 08/19/2014 07:54 PM, Christoph Hellwig wrote: >> On Sat, Aug 16, 2014 at 08:09:48PM -0700, K. Y. Srinivasan wrote: >>> The host asks the guest to scan when a LUN is removed or added. >>> The only way a guest can identify the removed LUN is when an I/O is >>> attempted on a removed LUN - the SRB status code indicates that the LUN >>> is invalid. We currently handle this SRB status and remove the device. >>> >>> Rather than waiting for an I/O to remove the device, force the >>> discovery of >>> LUNs that may have been removed prior to discovering LUNs that may have >>> been added. >> >> This looks pretty reasonable to me, but I wonder if we should move this >> up to common code so that it happens for any host rescan triggered by >> sysfs or other drivers as well. >> > Not without proper testing. > Currently we cannot rescan existing devices; the inquiry string is > nailed to the sdev structure. The only way to really refresh the > information is to delete it and rescan it again. How are distros handling 0x6/0x3f/0x0e (report luns changed) when it gets passed to userspace? Is everyone kicking off a new full (add and delete) scan to handle this or logging it? Is the driver returning this when the LUNs change? Also is the driver getting a 0x5/0x25/0 (invalid LUN) when the LUN does not exist, or is it just getting that SRB_STATUS_INVALID_LUN error code? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
