On Thu, 2012-05-31 at 09:40 -0700, Dan Williams wrote: > On Thu, May 31, 2012 at 1:21 AM, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > >> 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. > > Random timeouts are magic, waiting for known probing to complete is not. Well, yes it is ... it's just a question of whose magic timeouts. Probing mostly waits the device appearance timeout on the bus. The timeout in question is how long the user is prepared to wait for the root device. Most distros tend to code for 120s+, so that's way beyond any bus timeout. If the user wishes forever, that's fine too. > >> 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. > > I'm a savvy raid user who wants his raid arrays to start as soon as > possible and one that knows that lldds, libsas, and libata can inject > long unpredictable delays to discover devices that were attached since > boot. > > So it's not about hotplug it's about letting the initial scan / > discovery process (which may involve 3 resets and 1 minute of timeouts > per-disk in a pathological ata configuration) complete for devices > that were minimally indicated in the initial scan. The initramfs > timeout is then an optional cushion to allow a hotplug event to land, > but for the "as fast as possible case" that means letting link > recovery actions quiesce. If there are errors on the bus, the chances are the devices are missed by the initial discover and appear later anyway, so neither approach is foolproof. I like the how long is the user prepared to wait approach vs how long does it take to complete error recovery simply because mostly if the device doesn't appear within that time it is a bug (or a hardware configuration problem). Conversely, if you think of the usual case: the root device appears long before bus probing finishes, so by only waiting for root, we assist the fast boot process. 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
