Как я могу контролировать время простоя жесткого диска?

Посмотрите на hdparm .

Из руководства ( man hdparm в командной строке):

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

Итак, sudo hdparm -I /dev/sdb | grep level покажет текущее значение spindown, например:

Advanced power management level: 254

Из руководства: 254 зарезервировано, поэтому я ожидаю, что это будет по умолчанию Ubuntu (может ли кто-нибудь подтвердить или расширить это, пожалуйста?)

Пример:

sudo hdparm -S 25 /dev/sdb = spindown через 25 * 5 секунд.

sudo hdparm -S 245 /dev/sdb = spindown after (245-240) * 30 минут.

Дисковая утилита - > выберите жесткий диск - > нажмите на значок «Дополнительные действия ...» в правом верхнем углу - > Настройки накопителя ...

Mine выглядит так:

Если вам интересно, сделайте настройку hdparm постоянной между перезагрузками, вместо того, чтобы добавлять ее в crontab, вы можете использовать /etc/hdparm.conf . У меня есть следующее: обратите внимание на использование капитала S, а не строчного:

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

Добавьте эту строку, заменяющую UUID вашим, или вы также можете указать устройство, используя формат /dev/sdX . Вы можете узнать UUID вашего диска с помощью команды sudo blkid .

1. Найдите UUID вашего диска .

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

2. Изменить /etc/hdparm.conf

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

3. Найдите spindown-time или раздел настроек вашего диска.

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

4. Я предпочитаю ссылаться на диск по UUID, который остается неизменным для разных установок (если вы не измените его в самой HW).

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

5. Если сценарий init вызывает проблемы с загрузкой, вы можете передать nohdparm в командной строке ядра, и сценарий не будет запущен.

Потратив часы и часы, я обнаружил, что мой накопитель WDC не поддерживает команду hdparm -S, независимо от значения атрибута idle3 (google: idle3ctl). И это обычная проблема с дисками WD. Но я рад сообщить, что hd-idle ( Ссылка ) работает безупречно. Если он установлен из пакета dpkg-builded (см. Примечания к установке), он создает демон как для ubuntu, так и для debian (config находится в / etc / default / hd-idle). Хорошо работает после возобновления спячки.

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

Я обнаружил, что поведение spindown в Samsung HD204UI зависит от уровня APM ( hdparm -B ). Если уровень APM равен 127, тайм-аут spindown составляет 10 с. Если уровень APM равен 150, тайм-аут spindown определяется опцией -S .

Я добавляю что-то вроде:

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

для корневого корня. Использование uuid лучше, я думаю, потому что sda / sdb и т. Д., Похоже, меняется при каждой перезагрузке

В Ubuntu 14.04

Диски > выделить дисковод > щелкните шестерню в верхнем правом углу > Настройки привода > теперь у вас есть настройки режима ожидания, APM, AAM и Write Cache в удобном графическом интерфейсе!

В Debian с дисками WD я обнаружил, что установка любого уровня с hdparm -S приводит к тому, что диск возвращает уровень 254 на следующий hdparm -I . Поэтому я действительно не уверен, что они крутятся или нет. Я думаю, они все еще вращаются.

Эти диски находятся на массиве серверов, и я действительно не хочу, чтобы они когда-либо вращались. Раньше я клонировал это, установив задание cron для обновления файла каждые несколько минут.

Мне не повезло с hdparm на внешнем жестком диске, смонтированном в USB-корпусе, который я использую для обслуживания мультимедиа с мини-монитором.

Мне пришла в голову идея отсюда: Ссылка

Лучшие результаты исходят от использования uuid диска, который вы можете найти с помощью:

sudo blkid

Следующий метод требует доступа root, но также hdparm. Это использует crontab для чтения случайного блока с диска каждые 5 минут и игнорирует все сообщения. Чтобы убедиться, что у вас есть правильный UUID, проверьте его в командной строке следующим образом (убедитесь, что вы используете нужный UUID, а не этот):

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

Вы должны увидеть вывод следующим образом:

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

Чтобы подавить это сообщение, которое в конечном итоге может быть написано где-то, потенциально / файловая система (которая находится на SSD в моем случае), ниже - это то, что я использую в корневом каталоге crontab. Вы попадаете туда с

sudo crontab -e

Затем под комментариями:

*/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

Надеюсь, это поможет кому-то еще с подобными проблемами. К сожалению, это все еще записывается в syslog, но есть потенциальные способы подавить это; см. этот пост ServerFault .

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

Я смог подавить эти сообщения, отредактировав /etc/rsyslog.d/50-default.conf, чтобы изменить эту строку:

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

:

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

К сожалению, это подавляет все сообщения cron; Я не мог заставить cron перенаправлять ведение журнала с корневой файловой системы (которая находится на стареющем SSD в моем случае, поэтому я хочу ограничить запись), но поскольку это всего лишь домашний сервер, я, вероятно, не пропускаю много. Определенно не рекомендовать эту стратегию для производственной машины.