Re: [PATCH] sd: sd should not modify read capacity, cache type or write protect flag on rescan when there is a transport error

[Mike Christie <michaelc@cs.wisc.edu>]

On 03/10/2011 02:49 AM, Menny_Hamburger@Dell.com wrote:
> Mike,
>
> I think there are still two open issues still here:
> 1) Should we always rescan when transport comes back up? My own opinion to this question is that doing a full rescan may be an overkill

I think we should always rescan. The values could have changed on the 
target even if we have not actually sent a command and had it failed, so 
either way we need to pick up new values.

>     In this case. If the decision is not to rescan always (only when we have invalid capacity, cache type, write protect flag), we will need to maintain
>     Additional state information in the device to indicate that the current values are invalid and a rescan is required.
>     James stated that it is a layering violation to test the host byte of the result in order to decide whether or not a rescan is required, so we will
>     need setup this state information in any case of failure when getting these properties from the device.
> 2) Should we rescan from within the kernel, or issue a uevent (hotplug) that would be picked up by userland (that would initiate the rescan)?
>     Rescanning from within the kernel seems a bit more "clean", however there may be other considerations here.

Kernel. In the iscsi and fc class we already do a scan for devices when 
the transport comes back up from the kernel, so this rescan of devices 
values can just run from the same function.