Hi Bart, > On Jan 17, 2018, at 3:24 PM, Bart Van Assche <[email protected]> wrote: > > When the SCSI scanning code discovers a SCSI device it calls the driver core > function device_add() to associate a SCSI ULD with the device. The driver > core invokes the probing function for the matching SCSI ULP, e.g. sd_probe(). > In order to minimize the time needed to scan SCSI targets that have a large > number of LUNs, the SCSI disk driver scans LUNs asynchronously by starting > the actual probing work asynchronously from inside sd_probe() > > An unfortunate aspect of how SCSI disk probing works today is that there is > unnecessary serialization between probing and removal activity. For a > possible approach of how to increase SCSI disk probing concurrency, see also > [PATCH] sd: Increase SCSI disk probing concurrency, linux-scsi mailing list, > December 2017 (https://www.spinics.net/lists/linux-scsi/msg115657.html). > > A second unfortunate aspect of SCSI disk probing is that certain race > conditions in the block layer are hit if removal starts before asynchronous > probing has finished. This is because the driver core is unaware that the > SCSI disk code works asynchronously. > > Additionally, the SCSI disk asynchronous probing approach is incompatible > with the power management code. The power management code calls > wait_for_device_probe() in the driver core to wait for device probing > activity to finish. wait_for_device_probe() however is unaware of the > asynchronous probing in the SCSI sd driver and hence doesn't wait for the > SCSI sd probing activity to finish. > > My proposal is to hold a session to discus potential solutions for > increasing SCSI disk probing concurrency in a way that is compatible with > the driver core and the power management subsystem.
We have run into issue with asyc probing and would be interested in the discussion. Thanks, - Himanshu
