Да, упустил, речь шла о файле /usr/lib/pm-utils/power.d/harddrive.
Проверил, он точно задействован для спящего режима, цепочка вызова такова:
upowerd -> pm-hibernate -> 00powersave -> pm-powersave -> harddrive -> hdparm
Два вызова с параметрами: -W 1 -S 0 -B 254 -M 0 /dev/sda
Для ждущего режима я не отловил вызова hdparm. Тут возможны 2 варианта: 1) либо hdparm не вызывается вообще, либо 2) у меня VirtualBox выходит из ждущего раньше, чем успеет в него войти, либо 3) писать уже некуда.
Откуда дровишки? Рассказываю. ASL6 установлен в VirtualBox.
# mv /sbin/hdparm{,.orig}
# cat <<EOF > /sbin/hdparm
#!/bin/bash
LOG_FILE=/var/log/hdparm.log
echo -e "*** Parent: $PPID\nParameters: $@" >> $LOG_FILE
pstree -p >> $LOG_FILE
EOF
# chmod a+x /sbin/hdparm
Теперь вместо настоящего hdparm будет вызываться наш скрипт и записывать в файл /var/log/hdparm.log цепочку вызова, параметры и PID родительского процесса.
Затем отправил машину в спящий режим, получил в логе 2 вызова hdparm.
Затем попытался отправить машину в ждущий, правда она туда либо не дошла, либо без видимых причин вернулась с полдороги. В любом случае отметки о вызове hdparm в логе не оказалось.
Вернуть hdparm на место:
# mv /sbin/hdparm{.orig,}
Смотреть полученный лог удобно так:
# grep -E 'Par|hdparm' /var/log/hdparm.log
Если есть у кого возможность, проверьте на реальном железе.
Про vm.swappiness пока говорить рано. Он уменьшит желание вытеснять страницы в своп на диске, но на остальные обращения к диску по чтению и на запись в журналы и иные обращения к диску не повлияет, а это по-прежнему будет приводить к раскрутке диска и подтормаживанию.
UPD:
В свете вышесказанного остался пока открытым вопрос по спящему режиму:
# export DRIVE_POWER_MGMT_BAT=254
переход в спящий режим, после возврата
# hdparm -B /dev/sda
# echo $DRIVE_POWER_MGMT_BAT
