[RFC] libata support for async scanning

[RFC] libata support for async scanning

[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.

Signed-off-by: Matthew Wilcox <matthew@wil.cx>

Index: ./drivers/scsi/libata-scsi.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/scsi/libata-scsi.c,v
retrieving revision 1.38
diff -u -p -r1.38 libata-scsi.c
--- ./drivers/scsi/libata-scsi.c	19 Apr 2006 04:55:59 -0000	1.38
+++ ./drivers/scsi/libata-scsi.c	13 May 2006 04:56:30 -0000
@@ -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);
 }
 

Re: [RFC] libata support for async scanning

[Jeff Garzik]

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.

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

Re: [RFC] libata support for async scanning

[Matthew Wilcox]

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().

Re: [RFC] libata support for async scanning

[Jeff Garzik]

Matthew Wilcox wrote:
> 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().

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