Диски (у корпусі usb) постійно прокидаються, навіть коли вони не встановлені

Налаштування

У мене корпус USB (Buffalo DriveStation Quad), що містить чотири диски, підключені до мого серверу nas (сервер ubuntu 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працює в демон-режимі (лише одна перевірка один раз на день), а також не повинно бути нічого іншого зондування накопичувачів. Отже, будь-які ідеї, що спробувати далі? Є корпус Buffalo USB просто хитрий (і робить це самостійно)?

Оновлення №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. Про всяк випадок, якщо хтось вважає це актуальним.

— Тоні
джерело

мій $ 02: спробуйте зупинити все на вашій машині (надмірні демони можуть дивитись навколо зондуючих пристроїв), використовуйте опцію кріплення у режимі часу.

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

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

— Тоні

Простий спосіб сказати, чи це корпус чи ваша ОС - це відкрутити накопичувачі, а потім відключити USB.

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

@qasdfdsaq, на жаль, ця Buffalo Drivestation оснащена якоюсь фантазійною функцією відключення живлення. Корпус відключається сам, коли кабель usb відключений. Навіть вимикач живлення має лише параметри «вимкнено» та «автоматично».

— Тоні

Лише знімок у темряві: перевірте обрізані контури updateb.conf та прив'яжіть кріплення, щоб ці шляхи були явно пропущені (послуга "знайти"); Хоча це може бути якась інша подібна послуга.

— Майкл

Це може бути трохи зайвим, але 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 ~]#

— steve
джерело