On Fri, Jan 17, 2014 at 5:41 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 17 Jan 2014, Tejun Heo wrote: > >> On Fri, Jan 17, 2014 at 03:15:54PM -0500, Alan Stern wrote: >> > You will have to argue this point with Phillip. >> > >> > If necessary, we could add a sysfs attribute to force a spin-up during >> > system resume. Or you could disable runtime PM for the disk, but that >> > has its own disadvantages. >> >> Isn't immediate spin-up trivial to implement from anywhere? I'm not >> sure whether we'll end up defaulting to the lazy behavior or not but >> if we do requiring userland to echo something to sysfs to configure >> immediate spin-up feels a bit silly when userland might as well just >> issue a dummy command to force spinup. > > Then turn it around. Make the new sysfs attribute enable a lazy > resume. > >> And, yes, I agree with Dan that avoiding spinup of harddrives on >> system resume seems a bit niche in its usefulness. suspend/resume >> cycle at the very least generates logs which most likely will be >> committed to the drive sooner or later. >> >> What kind of use cases are we expecting for the lazy behavior? > > The intention is that this will help on systems with more than one > disk drive. The one containing the core OS files and the journal will > certainly spin up right away, but the others may not. > > To tell the truth, I'm not sure how useful this feature would be to > most people. But there probably are a few, like Phillip, who will be > glad to have it. That seems like sufficient justification for adding > it. > Hmm, given that an ATA "start" command is just a "read verify" I wonder if this can be done more simply than tying runtime and system resume together. Could the lazy resume knob simply cause sd_resume to be skipped? The first real command that comes down will achieve the same effect. -- 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