Comment puis-je contrôler le temps d'arrêt de disque dur?

63

J'ai 2 disques durs sur mon PC. Ubuntu éteint le disque dur secondaire très rapidement après environ 15 minutes, ce qui est court pour moi. J'ai besoin de contrôler cette fois. Comment puis-je le faire?

J'ai essayé la gestion de l’alimentation de GNOME mais je ne l’ai pas trouvée utile.

    
posée user16295 03.05.2011 - 19:43
la source

10 réponses

57

Regardez hdparm .

Dans le manuel ( man hdparm sur la ligne de commande):

  

-S Définit le délai d'attente en attente (spindown) pour le lecteur. Cette valeur est utilisée par le lecteur pour déterminer le délai d'attente (sans activité du disque) avant d'éteindre le moteur de la broche pour économiser de l'énergie. Dans de telles circonstances, le lecteur peut prendre jusqu'à 30 secondes pour répondre à un accès ultérieur au disque, bien que la plupart des lecteurs soient beaucoup plus rapides.

     

L'encodage de la valeur de délai d'attente est quelque peu particulier. Une valeur de zéro signifie que "les délais d'attente sont désactivés": l'appareil ne passera pas automatiquement en mode veille. Les valeurs de 1 à 240 spécifient des multiples de 5 secondes, ce qui entraîne des délais d'attente de 5 secondes à 20 minutes. Les valeurs de 241 à 251 spécifient de 1 à 11 unités de 30 minutes, ce qui donne des délais de 30 minutes à 5,5 heures. Une valeur de 252 signifie un délai d'attente de 21 minutes. Une valeur de 253 définit un délai d'expiration défini par le fournisseur entre 8 et 12 heures et la valeur 254 est réservée. 255 est interprété comme 21 minutes plus 15 secondes. Notez que certains lecteurs plus anciens peuvent avoir des interprétations très différentes de ces valeurs.

Donc, sudo hdparm -I /dev/sdb | grep level affichera la valeur actuelle de la spindown, par exemple:

Advanced power management level: 254

A partir du manuel: 254 est réservé, donc je m'attends à ce qu'il s'agisse du défaut d'Ubuntu (quelqu'un peut-il confirmer / développer s'il vous plaît?)

Exemple:

sudo hdparm -S 25 /dev/sdb = spindown après 25 * 5 secondes.

sudo hdparm -S 245 /dev/sdb = spindown après (245-240) * 30 minutes.

    
réponse donnée Rinzwind 03.05.2011 - 19:53
la source
42

Utilitaire de disque - & gt; sélectionnez le lecteur de disque dur - & gt; Cliquez sur l'icône "Plus d'actions ..." dans le coin supérieur droit - & gt; Paramètres du lecteur ...

Le mien ressemble à ceci:

    
réponse donnée Ray 08.12.2013 - 14:26
la source
26

Si vous êtes intéressé par le paramétrage de hdparm persistant entre les redémarrages, au lieu de l’ajouter à la crontab, vous pouvez utiliser le /etc/hdparm.conf . J'ai le suivant, notez l'utilisation de majuscule S, pas minuscule:

command_line {
    hdparm -S 25 /dev/disk/by-uuid/f6c52265-d89f-43a4-b03b-302c3dadb215 
}

Ajoutez cette ligne en remplaçant l’UUID par le vôtre ou vous pouvez également spécifier le périphérique en utilisant le format /dev/sdX . Vous pouvez trouver l'UUID de votre disque avec la commande sudo blkid .

    
réponse donnée sergio.hs84 03.12.2012 - 12:04
la source
5

Après avoir passé des heures et des heures, j'ai découvert que mon lecteur WDC ne supportait pas la commande hdparm -S, quelle que soit la valeur de l'attribut idle3 (google: idle3ctl). Et c'est un problème courant avec les disques WD. Mais je suis heureux d'annoncer que hd-idle ( lien ) fonctionne parfaitement. S'il est installé à partir d'un paquet généré par dpkg (voir Notes d'installation), il crée un démon sur ubuntu et sur debian (config est dans / etc / default / hd-idle). Fonctionne bien après la reprise de l'hibernation.

mc default # ps aux | grep hd-idle | grep -v grep | cut -c 66- ; for f in [a-d] ; do hdparm -C /dev/sd$f | grep -v "^$" ; done
/usr/sbin/hd-idle -i 1800 -a sdc -i 600 -a sdd -i 60 -l /var/log/hd-idle.log
/dev/sda:
 drive state is:  active/idle
/dev/sdb:
 drive state is:  standby
/dev/sdc:
 drive state is:  standby
/dev/sdd:
 drive state is:  standby

    
réponse donnée user306935 15.02.2015 - 14:42
la source
5

J'ai découvert que le comportement de Samsung HD204UI dépend du niveau APM ( hdparm -B ). Si le niveau APM est 127, le délai d'attente de la spindown est de 10 s. Si le niveau APM est 150, le délai d'expiration de la spindown est défini par l'option -S .

    
réponse donnée beroal 13.02.2016 - 18:40
la source
5

J'ajoute quelque chose comme:

@reboot sudo hdparm -S244 /dev/disk/by-uuid/71492809-e463-41fa-99e2-c09e9ca90c8e  > /dev/null 2> /dev/null

pour rooter la crontab. Il est préférable d’utiliser uuid car sda / sdb etc. semble changer à chaque redémarrage

    
réponse donnée vidar uslingsen 28.08.2011 - 22:15
la source
4
  1. Recherchez l’UUID de votre disque .

    sudo lsblk --output NAME,FSTYPE,LABEL,UUID,MODE
    
  2. Modifier /etc/hdparm.conf

    sudo -H gedit /etc/hdparm.conf  # Be careful from now on
    
  3. Recherchez spindown-time ou la section des paramètres de votre disque.

    /dev/disk/by-label/4TB {
        spindown_time = 1200
    }
    
  4. Je préfère faire référence au disque par UUID qui reste le même sur les différentes installations (sauf si vous le modifiez dans le HW lui-même).

    /dev/disk/by-uuid/91e32677-0656-45b8-bcf5-14acce39d9c2 {
        spindown_time = 1200
    }
    
  5. Si le script init provoque des problèmes de démarrage, vous pouvez transmettre nohdparm sur la ligne de commande du noyau, et le script ne sera pas exécuté.

réponse donnée Ondra Žižka 04.05.2016 - 19:10
la source
3

Dans Ubuntu 14.04

Disques & gt; mettez en surbrillance drive & gt; Cliquez sur l'engrenage dans le coin supérieur droit & gt; Paramètres du lecteur & gt; Vous disposez maintenant de paramètres de veille, d’APM, d’AMA et de cache d’écriture dans une interface utilisateur facile à utiliser!

    
réponse donnée user245219 24.04.2014 - 23:37
la source
1

Sous Debian, avec les lecteurs WD, je trouve que la définition de n'importe quel niveau avec hdparm -S entraîne le retour du lecteur au niveau 254 sur hdparm -I . Donc, je ne suis vraiment pas sûr qu'ils tournent ou non. Je pense qu'ils continuent de tourner en rond.

Ces lecteurs sont sur une baie de serveurs et je ne veux vraiment pas qu’ils se dégradent. Dans le passé, je l'ai critiqué en définissant un travail cron pour mettre à jour un fichier toutes les quelques minutes.

    
réponse donnée dwasifar 01.05.2015 - 17:15
la source
1

Je n'ai pas eu de chance avec hdparm sur un disque dur externe monté dans un boîtier USB, que j'utilise pour servir de média avec minidlna.

J'ai trouvé une idée ici: lien

Les meilleurs résultats proviennent de l’utilisation de l’uuid du disque, que vous pouvez trouver avec:

sudo blkid

La méthode suivante nécessite un accès root, mais hdparm aussi. Cela utilise crontab pour lire un bloc aléatoire du lecteur toutes les 5 minutes et ignore tous les messages. Pour vous assurer que vous avez le bon UUID, testez-le sur la ligne de commande comme celle-ci (assurez-vous d'utiliser l'UUID souhaité, pas celui-ci):

sudo dd if=/dev/disk/by-uuid/f01df4b5-6865-476a-8d3b-597cbd886d41 of=/dev/null count=1 skip=$RANDOM

Vous devriez voir un résultat comme celui-ci:

1+0 records in
1+0 records out
512 bytes copied, 0.000738308 s, 693 kB/s'

Pour supprimer ce message, qui pourrait finir par être écrit quelque part, potentiellement le système de fichiers (qui se trouve sur un SSD dans mon cas), voici ce que j'utilise dans la crontab racine. Vous y arrivez avec

sudo crontab -e

Puis, sous les commentaires:

*/5 * * * * bash -c 'dd if=/dev/disk/by-uuid/f01df4b5-6865-476a-8d3b-597cbd886d41 of=/dev/null count=1 skip=$RANDOM' >/dev/null 2>&1

J'espère que cela aidera quelqu'un d'autre avec des problèmes similaires. Malheureusement, cela reste écrit dans le Syslog, mais il existe des moyens de le supprimer. voir cette publication ServerFault .

[modifier] 2017-01-07 09:02:

J'ai pu supprimer ces messages en éditant /etc/rsyslog.d/50-default.conf pour changer cette ligne:

*.*;auth,authpriv.none -/var/log/syslog

à ceci:

*.*;cron,auth,authpriv.none -/var/log/syslog

Malheureusement, cela supprime tous les messages cron; Je n'ai pas pu obtenir de rediriger la déconnexion du système de fichiers racine (qui se trouve sur un SSD vieillissant dans mon cas, donc je veux limiter les écritures), mais comme il ne s'agit que d'un serveur domestique, Ne recommanderais certainement pas cette stratégie pour une machine de production.

    
réponse donnée LawyerOnLinux 06.01.2017 - 12:03
la source

Lire d'autres questions sur les étiquettes