Les disques (dans le boîtier USB) continuent de se réveiller même lorsqu'ils ne sont pas montés

Installer

J'ai un boîtier USB (Buffalo DriveStation Quad) contenant quatre disques connectés à mon serveur nas (serveur ubuntu 14.04). Le boîtier est configuré en mode JBOD, donc je vais voir tous les disques dans Linux.

Deux des disques (sdb et sdc) sont configurés avec un raid logiciel en tant que /dev/md0(raid1). Et /dev/md0est monté en tant que partition unique ( /mnt/part1) avec le système de fichiers ext4 sans journalisation.

Les deux autres disques (sdd et sde) sont configurés avec LVM en tant que groupe de volumes, d'où j'ai monté deux partitions logiques. Dont l'un représente 90% de la capacité totale du groupe de volumes ( /mnt/part2) et l'autre 10% ( /mnt/part3). Les deux sont également ext4 sans journalisation.

Problèmes APM

Mes problèmes ont commencé avec les modes APM par défaut, car j'ai remarqué que la tête des disques durs se garait de manière assez agressive toutes les deux minutes. Après avoir fait quelques recherches sur le sujet, j'ai fini par utiliser hdparm -B198 /dev/sd[bcde]. Cela semble permettre un certain niveau d'économie d'énergie, mais sans vraiment faire de stationnement de tête.

Un sommeil?

Je suis plutôt satisfait de la situation actuelle, mais j'aimerais quand même que les lecteurs se mettent en veille s'il n'y a pas d'activité. Surtout les sdb et sdc ( /mnt/part1) qui n'obtiennent pas vraiment d'activité pendant 95% du temps. Quoi que j'aie essayé, le problème semble être que les disques ne dorment pas plus d'une minute ou deux.

Le démontage de toutes les partitions et l'émission hdparm -y /dev/sd[bcde]met les disques en mode veille, mais seulement pendant quelques minutes. Après cela, ils se réveilleront tous un par un. J'ai essayé de déboguer le problème en activant block_dump ( echo 1 > /proc/sys/vm/block_dump), mais je ne vois aucun accès aux disques.

J'ai également essayé de désactiver APM avec hdparm -B255 /dev/sd[bcde]et de leur ordonner de dormir après cela, mais la même chose. Les lecteurs se réveillent toujours après quelques minutes.

Je n'ai pas de mdadmfonctionnement en mode démon (juste une seule vérification une fois par jour), et il ne devrait rien y avoir d'autre à sonder les disques. Alors, quelles idées essayer ensuite? Le boîtier USB Buffalo est-il juste merdique (et cela se fait tout seul)?

Mise à jour # 1

J'ai pris du temps pendant combien de temps les disques se réveillent-ils après leur émission hdparm -y /dev/sd[bc]. Les horodatages suivants illustrent le modèle:

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

C'est à dire qu'il semble que quelque chose vérifie / réveille les disques toutes les 3 minutes. La première commande à passer en mode veille se trouvait à 40 secondes du point de contrôle.

Mise à jour # 2

Redémarré la machine avec acpi=off apm=off. N'a pas aidé non plus. Btw, la machine est un ordinateur portable Lenovo L520. Juste au cas où quelqu'un trouverait cela pertinent.

— Toni
source

mon $ .02: essayez d'arrêter tout sur votre machine (des démons trop zélés peuvent regarder autour pour sonder les périphériques), utilisez l'option de montage noatime.

— Laszlo Valko

@LaszloValko, a réussi à réduire les processus à upstart-{socket,file}-bridge, dhclient, getty and sshd- pas de chance :(. Il y a bien sûr beaucoup de processus du noyau en cours d'exécution (ceux répertoriés entre parenthèses). Je n'ai pas encore examiné si je pouvais les réduire par certains paramètres du noyau ... et lesquels seraient de bons candidats.

— Toni

Un moyen simple de savoir s'il s'agit du boîtier ou de votre système d'exploitation serait de faire tourner les disques puis de déconnecter l'USB.

— Circus Cat

@qasdfdsaq, malheureusement, ce Buffalo Drivestation est livré avec une fonction de mise hors tension de fantaisie. Le boîtier s'arrête immédiatement lorsque le câble USB est débranché. Même l'interrupteur d'alimentation n'a que les options "off" et "auto".

— Toni

Juste un coup dans le noir: vérifiez les chemins élagués et les montures de liaison de updatedb.conf, de sorte que ces chemins soient explicitement ignorés (service 'Locate'); cela pourrait facilement être un autre service similaire.

— michael

Cela peut être un peu exagéré, mais SystemTappourrait vous aider à identifier le processus qui fait des E / S sur ce disque.

Préparer SystemTap

[root@localhost ~]# stap-prep
snip

Installer le script de trace

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

Déterminez l'ID de l'appareil que vous souhaitez surveiller, dans ce cas, je vais surveiller / 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 ~]#

Surveillez, en utilisant le nombre majeur + mineur (8,5) en hex. Trouvez le coupable. Réjouir

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