У мене на комп'ютері є 2 жорсткі диски. Ubuntu вимикає вторинний жорсткий диск дуже швидко приблизно через 15 хвилин, що для мене коротко. Мені потрібно контролювати цей час. Як я можу це зробити?
Я спробував управління живленням GNOME, але не вважав його корисним.
Відповіді:
Погляньте hdparm.
З посібника ( man hdparmу командному рядку):
-S Встановіть час очікування (ззаду) для диска. Це значення використовується накопичувачем, щоб визначити, як довго чекати (без активності диска), перш ніж вимкнути шпиндельний мотор для економії енергії. За таких обставин, щоб відповісти на наступний доступ до диска, диску може зайняти 30 секунд, хоча більшість дисків набагато швидше.
Кодування значення тайм-ауту дещо своєрідне. Значення нуля означає «тайм-аути вимкнено»: пристрій не автоматично перейде в режим очікування. Значення від 1 до 240 задають кратні по 5 секунд, даючи час від 5 секунд до 20 хвилин. Значення від 241 до 251 вказують від 1 до 11 одиниць по 30 хвилин, що дає час від 30 хвилин до 5,5 годин. Значення 252 означає час очікування в 21 хвилину. Значення 253 встановлює визначений виробником період очікування від 8 до 12 годин, а значення 254 зарезервовано. 255 інтерпретується як 21 хвилина плюс 15 секунд. Зауважте, що деякі старі диски можуть мати дуже різні інтерпретації цих значень.
Так sudo hdparm -I /dev/sdb | grep levelбуде показано поточне значення Spindown, наприклад:
Advanced power management level: 254
З посібника: 254 зарезервовано, тому я очікую, що це за замовчуванням Ubuntu (може хто-небудь підтвердити / розширити цю проблему?)
Приклад:
sudo hdparm -S 25 /dev/sdb = затоплення через 25 * 5 секунд.
sudo hdparm -S 245 /dev/sdb = закваска після (245-240) * 30 хвилин.
grepдля APM ( -Bparm), але поговоріть про -Sповернення міста. Ви також знаєте щось про APM?
-Bпараметр відображається, як зазначено вище. Як я бачу поточну -Sнастройку?
sudo hdparm -y /dev/sdbвбиває звіра негайно
Disk Utility -> виберіть диск HDD -> натисніть на значок "Інші дії ..." у верхньому правому куті -> Налаштування диска ...
Моє виглядає так: 
gnome-disk-utility.
Якщо вас цікавить, чи налаштування 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.
command_lineданий час використовувати ? У мене є різні приклади в своєму /etc/hdparm?
sudo lsblk --output NAME,FSTYPE,LABEL,UUID,MODE
Редагувати /etc/hdparm.conf
sudo -H gedit /etc/hdparm.conf # Be careful from now on
Знайдіть spindown-timeабо розділ налаштувань вашого диска.
/dev/disk/by-label/4TB {
spindown_time = 1200
}
Я вважаю за краще посилатися на диск UUID, який залишається однаковим для різних установок (якщо ви не змінюєте його в самому HW).
/dev/disk/by-uuid/91e32677-0656-45b8-bcf5-14acce39d9c2 {
spindown_time = 1200
}
Якщо скрипт init викликає проблеми із завантаженням, ви можете передати nohdparm
командний рядок ядра, і сценарій не буде запускатися.
man hdparm.conf.
man hdparm.confопосередковано читає, що значення, передане -Sдля цього значення, для значень <255 повинно бути сумісним з правилом у верхній відповіді . Будь-яка додаткова інформація вітається.
Провівши години та години, я виявив, що мій диск WDC не підтримує команду hdparm -S, незалежно від значення атрибута idle3 (google: idle3ctl). І це поширена проблема з дисками WD. Але я радий повідомити, що hd-idle ( http://hd-idle.sourceforge.net/ ) працює бездоганно. Якщо встановлено з пакету, побудованого dpkg (див. Примітки щодо встановлення), він створює демон на ubuntu та debian (конфігурація знаходиться в / etc / default / hd-idle). Добре працює і після поновлення на сплячому режимі.
mc за замовчуванням # ps aux | grep hd-idle | grep -v grep | вирізати -c 66-; для f в [оголошення]; робити hdparm -C / dev / sd $ f | grep -v "^ $"; зроблено / usr / sbin / hd-idle -i 1800 -a sdc -i 600 -a sdd -i 60 -l /var/log/hd-idle.log / dev / sda: стан приводу: активний / непрацюючий / dev / sdb: стан приводу такий: режим очікування / dev / sdc: стан приводу такий: режим очікування / dev / sdd: стан приводу такий: режим очікування
Я виявив, що поведінка Spindown Samsung HD204UI залежить від рівня APM ( hdparm -B). Якщо рівень APM дорівнює 127, час очікування відростання становить 10 с. Якщо рівень APM дорівнює 150, час очікування відростання визначається -Sпараметром.
-Sопцію (див. Як визначити час повернення диска ). Щоб отримати його, використовуйте програмне забезпечення GUI "Disk". Іншу відповідь див. На скріншоті.
Я додаю щось на зразок:
@reboot sudo hdparm -S244 /dev/disk/by-uuid/71492809-e463-41fa-99e2-c09e9ca90c8e > /dev/null 2> /dev/null
до кореневого кронтабу. Я думаю, що використання uuid краще, тому що sda/ sdbetc., мабуть, змінюється з кожним перезавантаженням
hdparm.conf?
В Ubuntu 14.04
Диски> виділити диск> натисніть на шестерню у верхньому правому куті> Налаштування диска> тепер у вас є налаштування режиму очікування, APM, AAM та кешу запису у простому користуванні графічним інтерфейсом!
У Debian, з накопичувачами WD, я вважаю, що встановлення будь-якого рівня з hdparm -S призводить до того, що накопичувач повертає рівень 254 на наступному hdparm -I . Тож я справді не впевнений, вони крутяться вниз чи ні. Я думаю, вони все ще крутяться вниз.
Ці накопичувачі знаходяться на серверному масиві, і я дуже не хочу, щоб вони ніколи віджималися. Раніше я це хизувався, встановивши завдання cron оновлювати файл кожні кілька хвилин.
Мені не пощастило з hdparm на зовнішньому жорсткому диску, встановленому у корпусі USB, який я використовую для подачі носіїв із minidlna.
Я зіткнувся з ідеєю звідси: https://serverfault.com/questions/562738/keeping-usb-backup-drive-from-sleeping- while-mnged
Найкращі результати отримують від використання uuid диска, який ви можете знайти:
sudo blkid
Наступний метод вимагає кореневого доступу, але так само 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
Сподіваюсь, це допоможе комусь із подібними проблемами. На жаль, це все ще записується до системного журналу, але можливі способи придушити це; див. цю публікацію ServerFault .
[редагувати] 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, тому я хочу обмежити записи), але оскільки це лише домашній сервер, я, мабуть, багато чого не пропускаю. Однозначно не рекомендував би цю стратегію для виробничої машини.