I dischi (nella custodia USB) continuano a svegliarsi anche quando non sono montati

Impostare

Ho una custodia USB (Buffalo DriveStation Quad) contenente quattro unità collegate al mio server nas (server Ubuntu 14.04). Il contenitore è configurato in modalità JBOD, quindi vedrò tutti i dischi in Linux.

Due dei dischi (sdb e sdc) sono configurati con software raid come /dev/md0(raid1). Ed /dev/md0è montato come partizione singola ( /mnt/part1) con filesystem ext4 senza journaling.

Gli altri due dischi (sdd e sde) sono impostati con LVM come un gruppo di volumi, da cui ho montato due partizioni logiche. Uno dei quali è il 90% della capacità del gruppo a volume intero ( /mnt/part2) e uno al 10% ( /mnt/part3). Entrambi sono anche ext4 senza journaling.

Problemi di APM

I miei problemi sono iniziati con le modalità APM predefinite, poiché ho notato che la testa dei dischi rigidi era parcheggiata in modo abbastanza aggressivo ogni paio di minuti. Dopo aver studiato l'argomento per un po ', ho finito per usare hdparm -B198 /dev/sd[bcde]. Questo sembra consentire un certo livello di risparmio energetico, ma senza davvero fare alcun parcheggio.

Qualche sonno?

Sono abbastanza contento della situazione attuale, ma mi piacerebbe comunque che le unità andassero a dormire se non c'è attività. Soprattutto sdb e sdc ( /mnt/part1) che in realtà non ottengono alcuna attività per il 95% delle volte. Qualunque cosa abbia provato, il problema sembra essere che le unità non dormono più di un minuto o due.

Lo smontaggio di tutte le partizioni e l'emissione hdparm -y /dev/sd[bcde]metteranno le unità in modalità di sospensione, ma solo per alcuni minuti. Dopo di che si sveglieranno tutti uno per uno. Ho provato a eseguire il debug del problema abilitando block_dump ( echo 1 > /proc/sys/vm/block_dump), ma non vedo alcun accesso ai dischi.

Ho anche provato a disabilitare APM con hdparm -B255 /dev/sd[bcde], e ordina loro di dormire dopo, ma stessa cosa. Tuttavia, le unità si svegliano dopo un paio di minuti.

Non ho mdadmesecuzione in modalità demone (solo un singolo controllo una volta al giorno), né dovrebbe esserci qualcos'altro che analizza le unità. Quindi qualche idea su cosa provare dopo? La custodia USB Buffalo è semplicemente scadente (e lo fa da sola)?

Aggiornamento n. 1

Ho impiegato del tempo per la sveglia dei dischi dopo l'emissione hdparm -y /dev/sd[bc]. I seguenti timestamp illustrano il modello:

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

Cioè sembra che qualcosa controlli / riattivi i dischi ogni 3 minuti. Il primo comando per passare alla modalità standby è appena arrivato a 40 secondi dal checkpoint.

Aggiornamento n. 2

Riavvia la macchina con acpi=off apm=off. Non ha aiutato neanche. A proposito, la macchina è un laptop Lenovo L520. Nel caso in cui qualcuno lo ritenga rilevante.

— Toni
fonte

my $ .02: prova a fermare tutto sul tuo computer (i demoni troppo zelanti potrebbero guardarsi intorno per sondare i dispositivi), usa l'opzione di montaggio noatime.

— Laszlo Valko,

@LaszloValko, è riuscito a ridurre i processi a upstart-{socket,file}-bridge, dhclient, getty and sshd- nessuna fortuna :(. Naturalmente ci sono molti processi del kernel in esecuzione (quelli elencati tra parentesi). Non ho ancora esaminato se potrei ridurre quelli con alcuni parametri del kernel ... e quali sarebbero i buoni candidati.

— Toni,

Un modo semplice per stabilire se si tratta del contenitore o del sistema operativo in uso consiste nel ridurre le unità, quindi scollegare l'USB.

— Circo Gatto,

@qasdfdsaq, sfortunatamente questa Buffalo Drivestation ha alcune fantastiche funzioni di spegnimento. L'involucro si spegne immediatamente quando viene scollegato il cavo USB. Anche l'interruttore di accensione ha solo le opzioni "off" e "auto".

— Toni,

Solo uno scatto al buio: controlla i percorsi eliminati di updatedb.conf e monta i mount, in modo che questi percorsi vengano esplicitamente saltati (servizio "localizza"); potrebbe facilmente essere un altro servizio simile, comunque.

— michael,

Potrebbe essere un po 'eccessivo, ma SystemTappotrebbe aiutarti a identificare quale processo sta eseguendo l'I / O su quel disco.

Prepara SystemTap

[root@localhost ~]# stap-prep
snip

Installa script di traccia

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

Scopri l'id del dispositivo che vuoi monitorare, in questo caso vado a monitorare / 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 ~]#

Monitorare, utilizzando il numero maggiore + minore (8,5) in esadecimale. Trova colpevole. Rallegrarsi

[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
fonte