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. Alan Stern -- 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
