Re: Disk spin-up optimization during system resume

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

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux