J’ai eu le même problème très récemment. J’étais tombé sur une page qui expliquait assez bien le problème et qui tordait le cou à certaines idées reçue : difficile de savoir la vérité à ce sujet, mais ce que j’ai vécu confirme plutôt ce que j’y ai lu et je livre donc les conclusions, assez spéculatives, ici.
Mon disque dur présentait des signes évidents de fatigue : messages du noyau linux comme quoi il n’arrivait pas à lire sur le disque dur, toujours au même positions, les self-test smartctl -t me retournait des erreurs et le fameux Load_Cycle_Count rendu à plus de 1 000 000.
Premier point : il se peut que le Load_Cycle_Count retourné ne soit pas correct, il faut aussi regarder la colonne VALUE qui est un pourcentage (load_cycle_count disponible / load_cycle_count maximal), s’il tombe à 0 c’est pas bon du tout... Second point : il est indicatif, on peut tomber en panne largement en-dessous comme être largement au-dessus et parfaitement fonctionnel, prenez toutefois vos précautions, mais il va de soit que vous faites des sauvegardes régulièrement !
J’ai donc changé ce disque dur. Là encore quelques idées reçues qui semblent fausses : ce n’est pas nécessairement le paramétrage trop aggressif de Linux qui est en cause, en fait ça dépend totalement de l’ensemble (disque dur, ordinateur, os), il faut bien se dire que le fabricant a lui même mis en place une valeur par défaut, et que les bios des portables ne doivent sûrement pas se priver de régler ce genre de détails. En effet, sans activer aucun mode d’économie d’énergie sur ma distribution ou au niveau du noyau Linux je me retrouve toujours avec un ratio load_cycle_count / heure bien trop élevé (> 20—30) et le disque dur a son économie d’énergie activée (hdparm -B /dev/sda retourne 128).
La solution est alors de régler le niveau d’économie d’énergie avec hdparm. Personellement, le passer à 254 a définitivement réglé mon problème, sans que la température ne dépasse les 39° C. Il faut ensuite faire un script : là attention! il faut penser au démarrage de l’ordinateur, mais aussi à la sortie de veille (suspend-to-ram et suspend-to-disk) ; les distributions proposent normalement le moyen de régler ça, mais il faut mettre les mains dans le cambouis.
Votre problème est que ça chauffe. Ce que je ferais c’est d’accepter une valeur d’économie d’énergie faible (genre 128). Il y a ensuite des moyens de « limiter la casse » du Load_Cycle_Count : il s’agira de limiter les accès disque. Le mieux est de chercher du côté des économies d’énergies, et c’est ce que j’ai fait. Mais ça créé d’autres problèmes, il faudra donc faire un compromis. Par exemple, j’ai mis l’option relatime au montage des partition, j’ai augmenté la valeur de /proc/sys/vm/dirty_writeback_centisecs à 1500 (mais on peut aller au-delà si on veut, sur un portable avec batterie on peut se permettre de ne pas craindre les coupures), désactiver le swap peut être une idée aussi (quoi que de mon expérience, swap ⇒ cache disque plus grand ⇒ moins d’accès disque) et enfin il faut faire la chasse aux programmes qui réclament régulièrement des accès disques pour soit les supprimer, soit les configurer correctement (par exemple tout ce qui surveille activement la modification sur des fichiers est à bannir, il y a inotify pour ça, ou à défaut augmenter l’intervalle et râler/déposer un rapport de bug).
# Résultats de mes investigations
Posté par BB . En réponse au message Disque dur, température et Load_Cycle_Count. Évalué à 1.
Mon disque dur présentait des signes évidents de fatigue : messages du noyau linux comme quoi il n’arrivait pas à lire sur le disque dur, toujours au même positions, les self-test smartctl -t me retournait des erreurs et le fameux Load_Cycle_Count rendu à plus de 1 000 000.
Premier point : il se peut que le Load_Cycle_Count retourné ne soit pas correct, il faut aussi regarder la colonne VALUE qui est un pourcentage (load_cycle_count disponible / load_cycle_count maximal), s’il tombe à 0 c’est pas bon du tout... Second point : il est indicatif, on peut tomber en panne largement en-dessous comme être largement au-dessus et parfaitement fonctionnel, prenez toutefois vos précautions, mais il va de soit que vous faites des sauvegardes régulièrement !
J’ai donc changé ce disque dur. Là encore quelques idées reçues qui semblent fausses : ce n’est pas nécessairement le paramétrage trop aggressif de Linux qui est en cause, en fait ça dépend totalement de l’ensemble (disque dur, ordinateur, os), il faut bien se dire que le fabricant a lui même mis en place une valeur par défaut, et que les bios des portables ne doivent sûrement pas se priver de régler ce genre de détails. En effet, sans activer aucun mode d’économie d’énergie sur ma distribution ou au niveau du noyau Linux je me retrouve toujours avec un ratio load_cycle_count / heure bien trop élevé (> 20—30) et le disque dur a son économie d’énergie activée (hdparm -B /dev/sda retourne 128).
La solution est alors de régler le niveau d’économie d’énergie avec hdparm. Personellement, le passer à 254 a définitivement réglé mon problème, sans que la température ne dépasse les 39° C. Il faut ensuite faire un script : là attention! il faut penser au démarrage de l’ordinateur, mais aussi à la sortie de veille (suspend-to-ram et suspend-to-disk) ; les distributions proposent normalement le moyen de régler ça, mais il faut mettre les mains dans le cambouis.
Votre problème est que ça chauffe. Ce que je ferais c’est d’accepter une valeur d’économie d’énergie faible (genre 128). Il y a ensuite des moyens de « limiter la casse » du Load_Cycle_Count : il s’agira de limiter les accès disque. Le mieux est de chercher du côté des économies d’énergies, et c’est ce que j’ai fait. Mais ça créé d’autres problèmes, il faudra donc faire un compromis. Par exemple, j’ai mis l’option relatime au montage des partition, j’ai augmenté la valeur de /proc/sys/vm/dirty_writeback_centisecs à 1500 (mais on peut aller au-delà si on veut, sur un portable avec batterie on peut se permettre de ne pas craindre les coupures), désactiver le swap peut être une idée aussi (quoi que de mon expérience, swap ⇒ cache disque plus grand ⇒ moins d’accès disque) et enfin il faut faire la chasse aux programmes qui réclament régulièrement des accès disques pour soit les supprimer, soit les configurer correctement (par exemple tout ce qui surveille activement la modification sur des fichiers est à bannir, il y a inotify pour ça, ou à défaut augmenter l’intervalle et râler/déposer un rapport de bug).