Bah. Async scanning seems useful, but it shouldn't be a module option
that breaks exsiting users of the attribute, and it shouldn't be in
the FC transport class.
Just add a new async_scan attribute that works like scan, but works
asynchronously in the core.
Or figure out if we can overload the a
On Mon, Feb 22, 2016 at 08:51:02AM +0100, Hannes Reinecke wrote:
> When invoking a scan via the sysfs 'scan' attribute the process
> will be blocked until the scan is completed, which can take a
> very long time on large installations.
> Enabling the 'async_user_scan' parameter moves the actual
> L
Reviewed-by: Shane Seymour
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
When invoking a scan via the sysfs 'scan' attribute the process
will be blocked until the scan is completed, which can take a
very long time on large installations.
Enabling the 'async_user_scan' parameter moves the actual
LUN scanning to a workqueue, thereby unblocking the process.
Signed-off-by:
When invoking a scan via the sysfs 'scan' attribute the process
will be blocked until the scan is completed, which can take a
very long time on large installations.
Enabling the 'async_user_scan' parameter moves the actual
LUN scanning to a workqueue, thereby unblocking the process.
Signed-off-by:
5 matches
Mail list logo
