Перевести жесткий диск в спящий режим и будить его только при необходимости

Я хочу подключить еще один жесткий диск к своему компьютеру, но хочу, чтобы он спал 99% времени. Я буду использовать его только для нескольких вещей, но мне нужно, чтобы он был смонтирован в любое время.

Для этого я хотел бы знать:

1. Как я могу вести журнал, какие процессы обращаются к устройству? Мне нужно, чтобы журнал мог показать, из-за чего жесткий диск просыпается, если это происходит, чтобы я мог принять меры.
2. Есть ли особые настройки ядра, которые нужно сделать, чтобы устройство могло спать дольше?
3. Как задать интервалы сна для жесткого диска?

Интервал сна называется “APM” (Автоматическое управление питанием) и spindown_time. Это контролируется с помощью hdparm следующим образом:

hdparm -B 50 -S 36 /dev/disk/by-label/BACKUP-HDD

Это будут заставлять ваш HDD отключаться при ~3 минутах бездействия.

Опции объяснены:
-B 50 : активировать AMP с агрессивным управлением питанием
-S 36 : спать после 36 x 5 сек бездействия

См. man hdparm для получения дополнительных деталей

У меня похожая проблема. У меня SSD, /dev/sdb, с ОС (Linux Mint 18.1 на базе Ubuntu Xenial) и HDD, /dev/sda, с данными, которые я использую время от времени. Оба диска зашифрованы. Разделы HDD не смонтированы. И всё равно через несколько минут HDD просыпается, затем засыпает, затем снова просыпается. Путаница.

Вот дублирующий вопрос с полезным ответом, который предлагает auditd для поиска процесса-нарушителя.

apt-get install auditd
auditctl -w /dev/sda -p rwa

Затем я заставляю HDD заснуть с hdparm -Y /dev/sda. Потом жду, пока не услышу, что HDD снова начинает вращаться. Затем запускаю ausearch -f /dev/sda. В моем случае он показывает такие записи.

time->Sat Feb 25 12:38:17 2017
type=PROCTITLE msg=audit(1488022697.651:1744): proctitle=2F7573722F6C69622F756469736B73322F756469736B7364002D2D6E6F2D6465627567
type=PATH msg=audit(1488022697.651:1744): item=0 name="/dev/sda" inode=376 dev=00:06 mode=060660 ouid=0 ogid=6 rdev=08:00 nametype=NORMAL
type=CWD msg=audit(1488022697.651:1744):  cwd="https://serverfault.com/"
type=SYSCALL msg=audit(1488022697.651:1744): arch=c000003e syscall=2 success=yes exit=12 a0=f3fb90 a1=800 a2=7f4745221f64 a3=30 items=1 ppid=1 pid=18520 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pool" exe="/usr/lib/udisks2/udisksd" key=(null)

Релевантная часть exe=”/usr/lib/udisks2/udisksd”. Хотя у меня также был smartmontools, чей smartd также был проблемой. Я удалил smartmontools и остановил udisk2 сервис с service udisks2 stop. После этого HDD спит, как и ожидалось.

Обратите внимание, что udisks2 автоматически запустится, если я, например, открою приложение Disks, поэтому мне придется его снова остановить. Другим недостатком является то, что параметры SMART не мониторятся для обоих дисков, что не очень хорошо, но как временное решение это подходит.

Также одна вещь, которая не ясна, это то, что этот отчет о баге говорит, что udisks2 не делает опрос дисков, что теперь делает ядро. Но доказательства, похоже, указывают на обратное.

Так как вы находитесь на Linux, вы можете использовать новую утилиту fatrace, которая ведет журнал каждого доступа к файлу и сообщает, какой процесс за это отвечает:

https://launchpad.net/fatrace

Больше информации здесь:

http://www.piware.de/2012/02/fatrace-report-system-wide-file-access-events/

Она использует API linux fanotify (подробнее), доступное начиная с ядра linux 2.6.37.

fatrace не упакована во всех дистрибутивах по состоянию на июль 2014 (она недавно вошла в тестирование debian, так что должна поставляться в ‘jessie’), но ее легко установить из исходников.

http://en.wikipedia.org/wiki/Fuser_%28Unix%29 – fuser это UNIX-команда, используемая для отображения, какие процессы используют указанный файл, файловую систему или сокет.

http://sourceforge.net/projects/hdparm/ – получить/установить параметры ATA/SATA под Linux (смотрите опцию -S)

http://sg.danny.cz/sg/sg3_utils.html – Пакет sg3_utils содержит утилиты, которые отправляют SCSI команды устройствам. Как и устройства на транспорте, традиционно ассоциируемом с SCSI (ищите sg_start)

btrace или blktrace (оболочка для btrace) отслеживает блочные операции ввода-вывода в ядре и может помочь вам.

lsof +D /путь/к/монтажу должен показать вам каждый процесс, который открыл файл в указанном пути.