Summary: Re: Spin down HDD after disk sync or before power off

Garrett Cooper gcooper at FreeBSD.org
Wed Oct 27 13:02:02 UTC 2010


On Wed, Oct 27, 2010 at 5:54 AM, Alexander Best <arundel at freebsd.org> wrote:
> On Wed Oct 27 10, Garrett Cooper wrote:
>> On Wed, Oct 27, 2010 at 5:41 AM, Alexander Best <arundel at freebsd.org> wrote:
>> > On Thu Oct 21 10, Alexander Best wrote:
>> >> On Thu Oct 21 10, Bruce Cran wrote:
>> >> > On Thu, 21 Oct 2010 14:33:49 +0200
>> >> > Dag-Erling Smørgrav <des at des.no> wrote:
>> >> >
>> >> > > The problem with setting a short idle timeout is that, on a typical
>> >> > > laptop or desktop system, you end up spinning the disk down and back
>> >> > > up several hundred times a day, which increases power consumption, I/O
>> >> > > latency and wear.
>> >> >
>> >> > Do we think our users are silly enough to set a short timeout of just a
>> >> > few minutes?  I'd think most would use a setting of 20-30 minutes at
>> >> > a minimum. I never did understand why there were so many warnings;
>> >> > after all, some laptops even come with a default APM scheme in their
>> >> > HDDs that powers the disk down after 7 seconds!
>> >>
>> >> personally i still think something like the attached patch would be nice to
>> >> have. there's a chance users might type the following:
>> >>
>> >> 'atacontrol spindown device 10'
>> >>
>> >> thinking the timeout value is measured in minutes. although this gets mentioned
>> >> in atacontrol(4) it might still be worth reminding the user that he/she is
>> >> performing actions which could damage the hardware.
>> >
>> > i just stumbled upon PR 144770, where a somebody seems to have mistaken the
>> > spindown value for minutes instead of seconds. so i really think we should have
>> > this warning in atacontrol!
>> >
>> > +1 from brucec, if i understood him correctly.
>> >
>> > another possibility would be of course changing the spindown value from seconds
>> > to minutes. imo this seems very reasonable, because measuring spindown time in
>> > seconds is too fine grained and not intuitive. just like specifying the
>> > 'shutdown -p XX' delay in microseconds would not be useful. ;)
>> >
>> > cheers.
>> > alex
>> >
>> >>
>> >> cheers.
>> >> alex
>> >>
>> >> >
>> >> > --
>> >> > Bruce Cran
>> >>
>> >> --
>> >> a13x
>> >
>> >> diff --git a/sbin/atacontrol/atacontrol.c b/sbin/atacontrol/atacontrol.c
>> >> index 4354ddf..75a131a 100644
>> >> --- a/sbin/atacontrol/atacontrol.c
>> >> +++ b/sbin/atacontrol/atacontrol.c
>> >> @@ -317,6 +317,10 @@ ata_spindown(int fd, const char *dev, const char *arg)
>> >>
>> >>       if (arg != NULL) {
>> >>               tmo = strtoul(arg, NULL, 0);
>> >> +             if (tmo < 600)
>> >> +                     warnx("setting spindown timeout below 10 minutes is \
>> >> +                           not recommended (see EXAMPLES section of \
>> >> +                           atacontrol(8))\n");
>> >>               if (ioctl(fd, IOCATASSPINDOWN, &tmo) < 0)
>> >>                       err(1, "ioctl(IOCATASSPINDOWN)");
>> >>       } else {
>>
>>     Why not just be consistent with other interfaces and provide
>> suffixes for the values to parse out integral times (i.e. 1 [second],
>> 1m, 2h)? As long as the value is behavior is properly documented in
>> the manpage (and potentially as examples in the usage message), that
>> should be enough.
>
> that would increase usability, since users don't have to specify large values
> in seconds, if they e.g. want the spindown to happen after 24 hours (24*60*60).
> but this will not solve the real issue: specifying 'atacontrol spindown 1s'
> WILL damage your hardware! imo users should be reminded about this even if this
> is already mentioned in the manual.

    Maybe something similar to kern.geom.debugflags should be
implemented for this feature as a safety belt for people doing
something stupid?

> also: will current scripts which set 'atacontrol spindown 600' e.g. continue to
> work after implementing the use of suffixes?

    Yeah... why not :)?
Thanks!
-Garrett


More information about the freebsd-hackers mailing list