libata support for async scanning
RFC 1/1 libata support for async scanning
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.
Index: ./drivers/scsi/libata-scsi.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/scsi/libata-scsi.c,v retrieving revision 1.38
drivers/scsi/libata-scsi.c +3 -0
@@ -2733,16 +2733,19 @@ void ata_scsi_simulate(struct ata_port *void ata_scsi_scan_host (struct ata_port *ap) {struct ata_device *dev; +struct async_scan_data *data;unsigned int i;if (ap->flags &ATA_FLAG_PORT_DISABLED )return ; + data =scsi_prep_async_scan (ap->host);for (i =0 ; i <ATA_MAX_DEVICES ; i++) { dev = &ap->device[i];if (ata_dev_present (dev))scsi_scan_target (&ap->host->shost_gendev,0 , i,0 ,0 ); } +scsi_finish_async_scan (data); }
Quoted 6 lines · Matthew Wilcox
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.
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.
Jeff
Quoted 9 lines · Jeff Garzik
Quoted 6 lines · Matthew Wilcox
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.
Quoted 5 lines
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().
Quoted 25 lines · Matthew Wilcox
Quoted 8 lines · Jeff Garzik
Quoted 6 lines · Matthew Wilcox
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.
Quoted 1 line
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=2Without 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 toscsi_complete_async_scans()inscsi_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 callsscsi_finish_async_scan().
Quoted 8 lines
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().
First of all, let's establish the large I-dont-care factor on my part. I think its an academic exercise that none will notice, with respect to libata, but I won't NAK your patch...
Jeff