Re: [PATCH v5 3/3] scsi: async sd resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux