Диски (в корпусе USB) продолжают просыпаться, даже если они не установлены

Настроить

У меня есть USB-корпус (Buffalo DriveStation Quad), содержащий четыре накопителя, подключенных к моему nas-серверу (ubuntu server 14.04). Корпус настроен на режим JBOD, поэтому я посмотрю все диски в Linux.

Два диска (sdb и sdc) настроены с программным обеспечением raid как /dev/md0(raid1). И /dev/md0монтируется как один раздел ( /mnt/part1) с файловой системой ext4 без журналирования.

Два других диска (sdd и sde) настроены с LVM как одна группа томов, откуда я смонтировал два логических раздела. Один из которых составляет 90% от общей емкости группы томов ( /mnt/part2), а другой - 10% ( /mnt/part3). Оба также ext4 без журналирования.

Проблемы APM

Мои проблемы начались с режимами APM по умолчанию, так как я заметил, что голова жесткого диска припаркована довольно агрессивно каждые пару минут. Изучив тему немного, я использовалhdparm -B198 /dev/sd[bcde] . Это, кажется, позволяет некоторый уровень энергосбережения, но без необходимости делать парковку головы.

Есть сон?

Я в некотором роде доволен текущей ситуацией, но я все равно хотел бы, чтобы приводы засыпали, если нет активности. Особенно sdb и sdc ( /mnt/part1), которые действительно не получают никакой активности в течение 95% времени. Что бы я ни пробовал, похоже, проблема в том, что диски не спят дольше минуты или двух.

Размонтирование всех разделов и выдача hdparm -y /dev/sd[bcde]приведут накопители в спящий режим, но только на несколько минут. После этого они все проснутся один за другим. Я попытался отладить проблему, включив block_dump (echo 1 > /proc/sys/vm/block_dump ), но не вижу доступа к дискам.

Я также пытался отключить APM hdparm -B255 /dev/sd[bcde]и дать им команду спать после этого, но тоже самое. Тем не менее, диски просыпаются через пару минут.

Я не работаю mdadmв режиме демона (только одна проверка один раз в день), и не должно быть ничего другого, исследующего диски. Так что есть идеи, что попробовать дальше? Является ли USB-корпус Buffalo просто дрянным (и делает это самостоятельно)?

Обновление № 1

Я потратил много времени на то, чтобы диски проснулись после выпуска hdparm -y /dev/sd[bc]. Следующие временные метки иллюстрируют шаблон:

00:00 hdparm -y /dev/sd[bc]
00:40 disks start to wake up
00:59 disks fully awake
01:00 hdparm -y /dev/sd[bc]
03:40 disks start to wake up
03:59 disks fully awake
04:00 hdparm -y /dev/sd[bc]
06:40 disks start to wake up
06:59 disks fully awake

Т.е. кажется, что что-то проверяет / будит диски каждые 3 минуты. Первая команда для перехода в режим ожидания оказалась в 40 секундах от контрольной точки.

Обновление № 2

Перезагрузил машину с acpi=off apm=off. Тоже не помогло. Кстати, машиной является ноутбук Lenovo L520. На всякий случай, если кто-то посчитает это актуальным.

— Toni
источник

мои $ .02: попробуйте остановить все на вашем компьютере (чрезмерно усердные демоны могут смотреть на устройства-зонды), используйте опцию noatime mount.

— Ласло Валько

@LaszloValko, удалось сократить процессы до upstart-{socket,file}-bridge, dhclient, getty and sshd- не повезло :(. Конечно, запущено много процессов ядра (перечисленных в скобках). Еще не смотрел, смогу ли я уменьшить их по некоторым параметрам ядра ... и какие из них будут хорошими кандидатами.

— Тони

Простой способ определить, будет ли это корпус или ваша ОС, состоит в том, чтобы раскрутить диски и отключить USB.

— Цирковой кот

@qasdfdsaq, к сожалению, эта Buffalo Drivestation поставляется с необычной функцией отключения питания. Корпус отключается сразу же после отключения USB-кабеля. Даже выключатель питания имеет только опции «выкл» и «авто».

— Тони

Просто выстрел в темноте: проверьте обрезанные пути updatedb.conf & bind mounts, чтобы эти пути были явно пропущены (служба 'locate'); Впрочем, это может быть другой подобный сервис.

— Майкл

Может быть немного излишним, но SystemTapможет помочь вам определить, какой процесс делает ввод / вывод на этом диске.

Подготовьте SystemTap

[root@localhost ~]# stap-prep
snip

Установить скрипт трассировки

[root@localhost ~]# cat >/tmp/traceio2.stp
#! /usr/bin/env stap
global device_of_interest

probe begin {
  /* The following is not the most efficient way to do this.
      One could directly put the result of usrdev2kerndev()
      into device_of_interest.  However, want to test out
      the other device functions */
  dev = usrdev2kerndev($1)
  device_of_interest = MKDEV(MAJOR(dev), MINOR(dev))
}

probe vfs.write, vfs.read
{
  if (dev == device_of_interest)
        printf ("%s(%d) %s 0x%x\n",
            execname(), pid(), ppfunc(), dev)
}

Определите идентификатор устройства, которое вы хотите отслеживать, в этом случае я собираюсь контролировать / dev / sda5

[root@localhost ~]#  df -k /
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda5       18141508 16293424    903496  95% /
[root@localhost ~]# ls -l /dev/sda5
brw-rw----. 1 root disk 8, 5 Jul  1 01:21 /dev/sda5
[root@localhost ~]#

Монитор, используя старший + младший номер (8,5) в шестнадцатеричном. Найти виновника. Радуйтесь

[root@localhost ~]# /tmp/traceio2.stp 0x805
accounts-daemon(434) vfs_read 0x800005
accounts-daemon(434) vfs_read 0x800005
accounts-daemon(434) vfs_read 0x800005
lightdm(503) vfs_write 0x800005
bash(3036) vfs_read 0x800005
bash(3036) vfs_read 0x800005
^C
[root@localhost ~]#

— Стив
источник