lkml.org 
[lkml]   [2014]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2] Drivers: scsi: storvsc: Force discovery of LUNs that may have been removed.
    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?


    \
     
     \ /
      Last update: 2014-08-29 05:21    [W:2.480 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site