On Sat, May 13, 2006 at 01:16:46AM -0400, Jeff Garzik wrote: > Matthew Wilcox wrote: > >I don't think SATA target scanning occupies a huge amount of boot time, > >however it will currently force all async scanners to complete before it > >scans. The Rolls-Royce solution would be somethinkg akin to the new > >scsi_scan_host(), but I don't think that's necessaary. This patch just > >acknowledges that async scanning exists and will permit the drive > >additions to finish some time after libata has triggered the probe. > > This seems to add needless complexity. It doesn't, honest. > The internal probe is complete before the loop begins. Thus, > ata_scan_scan_host() is simply walking data structures in memory (due to > SCSI simulator) for ATA devices, and for ATAPI devices parallelism is > largely inadvisable :) Its overkill, and in some rare cases could make > debugging more annoying. It won't be parallelised with respect to itself, just with respect to other scsi scans. See my message http://marc.theaimsgroup.com/?l=linux-scsi&m=114735805518594&w=2 Without this patch (on top of that one), libata's calls to scsi_scan_target() will block until all asynchronous scans have completed (see the conditional call to scsi_complete_async_scans() in scsi_scan_target()). With this patch, libata will scan the targets in parallel with other scsi hosts scanning their targets. It will still block, but it'll do it later, when it calls scsi_finish_async_scan(). Hmm. Maybe I can improve the API such that scsi_finish_async_scan() won't make it block ... Anyway, the point here is actually to make your life easier. If someone has a lot of scsi hosts and libata doesn't have this patch, all of a sudden people are going to be asking you why libata's taking so long to initialise. And if you debug it, you'll find it's sleeping in scsi_complete_async_scans(). - : 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
