How can I control HDD spin down time?

Question

I have 2 HDDs in my PC. Ubuntu is turning off the secondary HDD very quickly after about 15 minutes, which is short for me. I need to control this time. How can I do it?

I tried GNOME power management but did not find it useful.

Answer 1

Have a look at hdparm.

From the manual (man hdparm on the command line):

-S Set the standby (spindown) timeout for the drive. This value is used by the drive to determine how long to wait (with no disk activity) before turning off the spindle motor to save power. Under such circumstances, the drive may take as long as 30 seconds to respond to a subsequent disk access, though most drives are much quicker.

The encoding of the timeout value is somewhat peculiar. A value of zero means "timeouts are disabled": the device will not automatically enter standby mode. Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21 minutes plus 15 seconds. Note that some older drives may have very different interpretations of these values.

So sudo hdparm -I /dev/sdb | grep level will show the current spindown value, for example:

Advanced power management level: 254

From the manual: 254 is reserved so I expect it to be Ubuntu's default (can anyone confirm/expand on this please?)

Example:

sudo hdparm -S 25 /dev/sdb = spindown after 25*5 seconds.

sudo hdparm -S 245 /dev/sdb = spindown after (245-240)*30 minutes.

Answer 2

Disk Utility -> select HDD drive -> click on the "More actions..." icon on the top right corner -> Drive settings...

Mine is looks like this:

Answer 3

If you're interested on do the hdparm's setting persistent between reboots, instead of adding it to the crontab, you can use the /etc/hdparm.conf. I have the following, note the use of capital S, not lowercase:

command_line {
    hdparm -S 25 /dev/disk/by-uuid/f6c52265-d89f-43a4-b03b-302c3dadb215 
}

Add that line replacing the UUID by yours, or also you may specify the device using /dev/sdX format. You can find out your disk's UUID with the command sudo blkid.

Answer 4

After spending hours and hours I discovered that my WDC drive do not support hdparm -S command, no matter idle3 attribute value (google: idle3ctl). And that is common problem with WD drives. But I'm pleased to announce that hd-idle (http://hd-idle.sourceforge.net/) works flawlessly. If installed from dpkg-builded package (see Installation notes), it creates daemon on both ubuntu and debian (config is in /etc/default/hd-idle). Works well after resuming from hibernation as well.

mc default # ps aux | grep hd-idle | grep -v grep | cut -c 66- ; for f in [a-d] ; do hdparm -C /dev/sd$f | grep -v "^$" ; done
/usr/sbin/hd-idle -i 1800 -a sdc -i 600 -a sdd -i 60 -l /var/log/hd-idle.log
/dev/sda:
 drive state is:  active/idle
/dev/sdb:
 drive state is:  standby
/dev/sdc:
 drive state is:  standby
/dev/sdd:
 drive state is:  standby

Answer 5

I discovered that the spindown behavior of Samsung HD204UI depends on the APM level (hdparm -B). If the APM level is 127, the spindown timeout is 10 s. If the APM level is 150, the spindown timeout is defined by the -S option.

Answer 6

I add something like:

@reboot sudo hdparm -S244 /dev/disk/by-uuid/71492809-e463-41fa-99e2-c09e9ca90c8e  > /dev/null 2> /dev/null

to root's crontab. Using uuid is better I think because sda/sdb etc. seems to change with every reboot

Answer 7

In Ubuntu 14.04

Disks > highlight drive > click the gear in the upper right hand corner > Drive Settings > now you have Standby, APM, AAM and Write Cache settings in an easy to use GUI!

Answer 8

1. Find your disk's UUID.

   sudo lsblk --output NAME,FSTYPE,LABEL,UUID,MODE
   

2. Edit /etc/hdparm.conf

   sudo -H gedit /etc/hdparm.conf  # Be careful from now on
   

3. Look for spindown-time or your disk settings section.

   /dev/disk/by-label/4TB {
       spindown_time = 1200
   }
   

4. I prefer to refer to the disk by UUID which remains the same across different installations (unless you change it in the HW itself).

   /dev/disk/by-uuid/91e32677-0656-45b8-bcf5-14acce39d9c2 {
       spindown_time = 1200
   }
   

5. If the init script causes boot problems, you can pass nohdparm on the kernel command line, and the script will not be run.

Answer 9

On Debian, with WD drives, I find that setting any level with hdparm -S results in the drive returning a level 254 on subsequent hdparm -I. So I'm really not sure if they're spinning down or not. I think they are still spinning down.

These drives are on a server array, and I really don't want them to ever spin down. In the past I've kludged this by setting a cron job to update a file every few minutes.

Answer 10

I had no luck with hdparm on an external HDD mounted in a USB enclosure, which I use to serve media with minidlna.

I came across an idea from here: https://serverfault.com/questions/562738/keeping-usb-backup-drive-from-sleeping-while-mounted

Best results come from using the disk's uuid, which you can find with:

sudo blkid

The following method does require root access, but so does hdparm. This uses crontab to read a random block from the drive every 5 minutes and ignores all messages. To make sure you have the right UUID, test it on the command line like this (make sure you use your desired UUID, not this one):

sudo dd if=/dev/disk/by-uuid/f01df4b5-6865-476a-8d3b-597cbd886d41 of=/dev/null count=1 skip=$RANDOM

You should see output like this:

1+0 records in
1+0 records out
512 bytes copied, 0.000738308 s, 693 kB/s`

To suppress this message, which could end up getting written somewhere, potentially the / filesystem (which is on an SSD in my case), below is what I'm using in the root crontab. You get there with

sudo crontab -e

Then, under the comments:

*/5 * * * * bash -c 'dd if=/dev/disk/by-uuid/f01df4b5-6865-476a-8d3b-597cbd886d41 of=/dev/null count=1 skip=$RANDOM' >/dev/null 2>&1

Hope this helps someone else with similar issues. Unfortunately, this still gets written to the syslog, but there are potentially ways to suppress that; see this ServerFault post.

[edit] 2017-01-07 09:02:

I was able to suppress these messages by editing /etc/rsyslog.d/50-default.conf to change this line:

*.*;auth,authpriv.none -/var/log/syslog

to this:

*.*;cron,auth,authpriv.none -/var/log/syslog

Unfortunately, this suppresses all cron messages; I could not get cron to redirect logging off the root filesystem (which is on an aging SSD in my case, so I want to limit writes), but as this is just a home server, I am probably not missing out on much. Would definitely not recommend this strategy for a production machine.