On Sat, 2014-03-15 at 16:35 -0700, Dan Williams wrote: > On Sat, Mar 15, 2014 at 2:47 PM, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 2014-03-14 at 13:11 -0700, Dan Williams wrote: > >> On Mon, Mar 10, 2014 at 11:29 PM, James Bottomley > >> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > >> >> > In the long game, though this whole debate is moot: setups with hard > >> >> > wired start times adhere to them regardless of what the system does, so > >> >> > they ignore start unit commands. Systems without hard wired start times > >> >> > can usually be started at once, so us introducing a delay is unnecessary > >> >> > in either case. > >> >> > >> >> Ok, then I'll let the patch stand as is. > >> > > >> > Sounds good. > >> > > >> > James > >> > > >> > > >> > >> Well, one more chirp about this. If the user has disabled async > >> scanning by CONFIG_SCSI_SCAN_ASYNC=n or scsi_mod.scan != "async" then > >> resume should follow suit. I'll include this in the next rev. > > > > Hm, OK, if this is tied at the hip to async scanning, why do you need > > another async domain for it? Why not just use the current async > > scanning domain ... it will actually probably resolve a few nasty (but > > wholly manufactured) races where scanning races with suspend. > > I considered that initially, but it ends up destroying most/all of the > benefit of doing it asynchronously. This is due to the fact that > scsi_sd_probe_domain is flushed by the async_synchronize_full() > performed in dpm_resume(). We want userspace to resume while the disk > may still be starting. OK, finally got it, the new domain doesn't participate in async_synchronize_full() but scsi_sd_probe_domain does (and has to because of the device and module operations). That might actually be worth a comment somewhere. 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
