All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Matthew Wilcox <matthew@wil.cx>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [RFC] libata support for async scanning
Date: Sat, 13 May 2006 21:26:04 -0400	[thread overview]
Message-ID: <4466872C.5010201@garzik.org> (raw)
In-Reply-To: <20060513131639.GT12272@parisc-linux.org>

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



      reply	other threads:[~2006-05-14  1:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-13  5:05 [RFC] libata support for async scanning Matthew Wilcox
2006-05-13  5:16 ` Jeff Garzik
2006-05-13 13:16   ` Matthew Wilcox
2006-05-14  1:26     ` Jeff Garzik [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4466872C.5010201@garzik.org \
    --to=jeff@garzik.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=matthew@wil.cx \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.