On 03/10/2011 02:49 AM, Menny_Hamburger@xxxxxxxx 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.
--
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
