On 08/27/2014 09:31 AM, Hannes Reinecke wrote:Currently it's logged to userspace and ignored.
On 08/19/2014 07:54 PM, Christoph Hellwig wrote:
On Sat, Aug 16, 2014 at 08:09:48PM -0700, K. Y. Srinivasan wrote:Not without proper testing.
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.
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?