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

Garrett Cooper gcooper at FreeBSD.org
Thu Sep 16 02:37:37 UTC 2010


On Wed, Sep 15, 2010 at 5:49 PM, Alexander Best <arundel at freebsd.org> wrote:
> On Wed Sep 15 10, Oliver Fromme wrote:
>> Warren Block <wblock at wonkity.com> wrote:
>>  > [...]
>>  > 8. Alexander Motin has an updated CAM version of the ATA system which
>>  > will eventually replace the existing one.  In -CURRENT, anyway.  He was
>>  > kind enough to look at my event handler.  My understanding is that he is
>>  > looking at implementing the head parking/standby mechanism in that new
>>  > code.
>>
>> The patch below will work with the new CAM ATA driver
>> (i.e. ada(4) disks).  It adds a sysctl, so you can switch
>> the spin-down off if you're going to just reboot:
>> # sysctl kern.cam.ada.spindown_shutdown=0
>
> i haven't tested your patch yet, but i don't think deciding whether to spin
> down the hdd should be decided merely from the sysctl value.
>
> the hdd should spindown when a shutdown has been issued and not spindown,
> if a reboot has been issued.
>
> either people have the sysctl set to 1 in which case a reboot will cause a
> spindown (which isn't healthy for the hdd)
> ...or people will set it to 0 in which case everything remains just the way it
> is.
>
> imo the sysctl should stay, but shuld have a different meaning. if it is set to
> 1 (which should be the default) a shutdown will issue a spindown; a reboot
> won't.
> if for some reason people want back the current behavior (no spindown even
> during a shutdown) they need to set it to 0.

Agreed. Spinning down at reboot isn't smart and seems like a good way
to kill a disk quicker.

> deciding whether freebsd reboots or shuts down cannot be done from a script,
> since users might use the reboot or halt commands in which case (if i'm not
> mistaken) all shutdown scripts get skipped.

I'm not so sure of that statement, in particular because halt(8),
reboot(8), and shutdown(8) send SIGTERM to processes (unless you use
halt -q / reboot -q ... there might be some other scenarios I'm not
envisioning here).

Thanks,
-Garrett


More information about the freebsd-hackers mailing list