Dyski (w obudowie USB) budzą się, nawet jeśli nie są zamontowane

Ustawiać

Mam obudowę USB (Buffalo DriveStation Quad) zawierającą cztery napędy podłączone do mojego serwera NAS (Ubuntu Server 14.04). Obudowa jest skonfigurowana do pracy w trybie JBOD, więc zobaczę wszystkie dyski w Linuksie.

Dwa dyski (sdb i sdc) są skonfigurowane z oprogramowaniem raid jako /dev/md0(raid1). I /dev/md0jest montowany jako pojedyncza partycja ( /mnt/part1) z systemem plików ext4 bez dzienników.

Pozostałe dwa dyski (sdd i sde) są skonfigurowane z LVM jako jedna grupa woluminów, z której zamontowałem dwie partycje logiczne. Jeden z nich stanowi 90% pojemności całej grupy woluminów ( /mnt/part2), a drugi to 10% ( /mnt/part3). Oba są również ext4 bez dzienników.

Problemy z APM

Moje problemy zaczęły się od domyślnych trybów APM, ponieważ zauważyłem, że dyski twarde zaparkowały dość agresywnie co kilka minut. Po dłuższym przestudiowaniu tematu skończyłem używać hdparm -B198 /dev/sd[bcde]. Wydaje się, że pozwala to na pewien poziom oszczędności energii, ale tak naprawdę nie wymaga parkowania.

Jakiś sen?

Jestem trochę zadowolony z obecnej sytuacji, ale nadal chciałbym, aby dyski poszły spać, jeśli nie ma żadnej aktywności. Zwłaszcza sdb i sdc ( /mnt/part1), które tak naprawdę nie uzyskują żadnej aktywności przez 95% czasu. Cokolwiek próbowałem, problem polega na tym, że dyski nie śpią dłużej niż minutę lub dwie.

Odmontowanie wszystkich partycji i wydanie hdparm -y /dev/sd[bcde]spowoduje przejście dysków w tryb uśpienia, ale tylko na kilka minut. Potem wszyscy obudzą się jeden po drugim. Próbowałem debugować problem, włączając block_dump ( echo 1 > /proc/sys/vm/block_dump), ale nie widzę żadnego dostępu do dysków.

Próbowałem też wyłączyć APM hdparm -B255 /dev/sd[bcde]i nakazać im spać po tym, ale to samo. Nadal dyski budzą się po kilku minutach.

Nie mam mdadmuruchomionego w trybie demona (tylko jeden test raz dziennie), ani też nie powinno być nic więcej sondowania dysków. Masz jakieś pomysły na kolejne próby? Czy obudowa Buffalo USB jest po prostu kiepska (i robi to sama)?

Aktualizacja nr 1

Poświęciłem czas na to, jak długo dyski się budzą po wydaniu hdparm -y /dev/sd[bc]. Poniższe znaczniki czasu ilustrują wzorzec:

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

Tzn. Wydaje się, że coś sprawdza / budzi dyski co 3 minuty. Pierwsze polecenie przejścia w tryb gotowości właśnie przypadło 40 sekund od punktu kontrolnego.

Aktualizacja nr 2

Uruchom ponownie maszynę za pomocą acpi=off apm=off. To też nie pomogło. Btw, maszyną jest laptop Lenovo L520. Na wypadek, gdyby ktoś uzna to za istotne.

— Toni
źródło

my $ .02: spróbuj zatrzymać wszystko na swoim komputerze (nadgorliwe demony mogą rozglądać się w poszukiwaniu urządzeń), użyj opcji montowania noatime.

— Laszlo Valko,

@LaszloValko, udało się zredukować procesy do upstart-{socket,file}-bridge, dhclient, getty and sshd- bez powodzenia :(. Oczywiście działa wiele procesów jądra (wymienionych w nawiasach). Nie zastanawiałem się jeszcze, czy mógłbym je zmniejszyć o niektóre parametry jądra ... i którzy byliby dobrymi kandydatami

— Toni

Prostym sposobem na stwierdzenie, czy jest to obudowa, czy też system operacyjny będzie spulchniał dyski, a następnie odłącz USB.

— Circus Cat

@qasdfdsaq, niestety to Buffalo Drivestation ma jakąś fantazyjną funkcję wyłączania. Obudowa wyłącza się natychmiast po odłączeniu kabla USB. Nawet wyłącznik zasilania ma tylko opcje „wyłączony” i „automatyczny”.

— Toni,

Tylko strzał w ciemność: sprawdź przycięte ścieżki zaktualizowaneb.conf i wiązania mountów, aby ścieżki te zostały wyraźnie pominięte (usługa „zlokalizuj”); może to być jednak inna podobna usługa.

— Michael

Może to być nieco przesada, ale SystemTapmoże pomóc w określeniu, jaki proces wykonuje operacje we / wy na tym dysku.

Przygotuj SystemTap

[root@localhost ~]# stap-prep
snip

Zainstaluj skrypt śledzenia

[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)
}

Sprawdź identyfikator urządzenia, które chcesz monitorować, w tym przypadku będę monitorować / 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 ~]#

Monitoruj, używając głównej + dodatkowej liczby (8,5) w systemie szesnastkowym. Znajdź winowajcę. Cieszyć

[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
źródło