On Wed, 2012-05-30 at 19:34 -0700, Dan Williams wrote: > On Wed, May 30, 2012 at 4:32 PM, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2012-05-30 at 11:26 -0700, Dan Williams wrote: > >> On Mon, May 28, 2012 at 5:07 AM, James Bottomley > >> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > >> > On Mon, 2012-05-28 at 10:00 +0000, maximilian attems wrote: > >> >> On Sun, May 27, 2012 at 10:13:46AM +0100, James Bottomley wrote: > >> >> > scsi_wait_scan was introduced with asynchronous host scanning as a hack > >> >> > for distributions that weren't using proper udev based wait for root to > >> >> > appear in their initramfs scripts. In 2.6.30 Commit > >> >> > >> >> > c751085943362143f84346d274e0011419c84202 > >> >> > Author: Rafael J. Wysocki <rjw@xxxxxxx> > >> >> > Date: Sun Apr 12 20:06:56 2009 +0200 > >> >> > > >> >> > PM/Hibernate: Wait for SCSI devices scan to complete during resume > >> >> > > >> >> > Actually broke scsi_wait_scan because it renders > >> >> > scsi_complete_async_scans() a nop for modular SCSI if you include > >> >> > scsi_scans.h (which this module does). > >> >> > > >> >> > The lack of bug reports is sufficient proof that this module is no > >> >> > longer used. > >> >> > >> >> We do use it in initramfs-tools. > >> >> > >> >> There is quite a number of bug reports moaning about having to boot with > >> >> `scsi_mod.scan=sync'. I didn't pass them on, because I didn't knew that > >> >> the module itself got broken, for example: > >> >> http://bugs.debian.org/616689 > >> > > >> > OK, so what these bugs show is the breakage ... basically scsi_wait_scan > >> > isn't really waiting for the scans to complete. I can fix it in stable > >> > so you can close your bug reports, but if I do, can you also transition > >> > away from using it so I can remove it in 3.5? > >> > >> Is there some other method whereby userspace can sync all driver > >> probing actions? > > > > No, but then there never really was. The theory is you know all the > > disks you need (/ /usr and so on) and you just wait for them to appear > > before mounting them and proceeding with boot. > > > >> We won't need scsi_complete_async_scans() after: > >> > >> http://marc.info/?l=linux-scsi&m=133840132007532&w=2 > >> > >> ...but won't initramfs environments still need a way to trigger > >> wait_for_device_probe()? Something like echo "flush" > > >> /sys/devices/async_probe. and maybe reading that file indicates if > >> some async probing is still in-flight? > > > > Why? The job of an initramfs is to mount root. All it has to do is > > wait for root to appear via udev and then proceed. The whole reason for > > doing stuff async initially was to speed boot, so probing can still be > > ongoing even after the initrd exits. > > > > If you think about it, most modern fabrics are hot plug. Just because > > the initial scan has completed there's no guarantee that all the devices > > have appeared yet. > > Fine for single device root, but what about raid and degraded assembly? > > Last time I checked scsi_wait_scan was still being used by dracut in > the case where it decides to stop waiting for all raid members to > appear. It's a "last call" before proceeding with degraded assembly. That's pretty pointless behaviour, isn't it? What it's basically doing is allowing a set time for the devices to appear, waiting out that time (so presumably something is wrong with one or more of the devices), then inserting scsi_wait_scan as some type of magic incantation to just make it work. > If you immediately assemble and mount root as soon as the root device > could be started it will almost always be a degraded array. Sure the > initramfs can just timeout arrival, but at a minimum that timeout > should be "load module + flush scanning". Without a flush mechanism > it's just a shot in the dark what that minimum timeout should be. No, you wait a specified time for all the devices to appear before assembling the raid. If they don't, you try to bring a degraded raid up. The behaviour is also dependent on the user: If I'm a savvy user and I have a raid log, I want my system up as fast as possible, so I only want to wait until the minimum number of devices appears before assembling the raid and moving on, knowing that hotplug of the remaining will cause a log replay. > If ata error recovery is kicking in and needs 10s of seconds to > recover a drive I'd want my initramfs to wait for that process to > quiesce before timing out and moving on. That's the timeout you specify. James -- To unsubscribe from this list: 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
