linux-kernel - Re: [PATCH] async scsi scanning, version 13

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 02 Oct 2006 12:02:14 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Matthew Wilcox <matthew@....cx>
CC:	James Bottomley <James.Bottomley@...elEye.com>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] async scsi scanning, version 13

Matthew Wilcox wrote:
> Add ability to scan scsi busses asynchronously
> 
> Since it often takes around 20-30 seconds to scan a scsi bus, it's
> highly advantageous to do this in parallel with other things.  The bulk
> of this patch is ensuring that devices don't change numbering, and that
> all devices are discovered prior to trying to start init.  For those
> who build SCSI as modules, there's a new scsi_wait_scan module that will
> ensure all bus scans are finished.
> 
> This patch only handles drivers which call scsi_scan_host.  Fibre Channel,
> SAS, SATA, USB and Firewire all need additional work.

A note on FireWire/ SBP-2's status: We basically scan* asynchronously,
although the scans are serialized across all FireWire devices on all
buses. Parallelized scanning is on my long term to-do list. Serialized
scanning is actually quick enough unless something goes wrong.

Integration of sbp2 with scsi_wait_scan is now on my to-do list too. It
is orthogonal to parallelized scanning as a feature but probably
somewhat coupled when it comes to an actual implementation.

So far, the few people who have the root filesystem (or any other
filesystem that they want to have ready on boot) on an SBP-2 disk simply
put a sleep into their initrd or run a more or less complete hotplug
environment from initrd. The scsi_wait_scan module would certainly be
more comfortable than that.

[ *) "scan" = read ISO 13213 configuration ROMs, then run protocol
     driver probes including sbp2's login ]
-- 
Stefan Richter
-=====-=-==- =-=- ---=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/