En voulant bien faire et allonger l'autonomie des Laptops les mainteneurs d'Ubuntu ont pris le risque de réduire de façon considérable la durée de vie des disques durs.
http://www.beranger.org/index.php?page=diary&2007/10/24/(...)
Certes il existe un fixe (changer à l'aide de hdparam certain paramètres) mais ils n'en font pas vraiment de la pub.
Ce qui est regrettable c'est la réaction du mainteneur qui cherche à minimiser sa boulette (seul les machines utilisant le mode LAPTOP_MODE sont touchées) et il avoue que cela réduit "un peu" la durée de vie des disques durs. A priori 11 à 12 mois de durée de vie s'est largement suffisant.
Ce bug existerait aussi pour 7.04 et 7.10.
Journal Canonical aurait des actions de fabricants de disques durs!
25
oct.
2007
# re
Posté par Sylvain (site web personnel) . Évalué à 7.
[^] # Re: Dell va avoir des problèmes de garantie.....
Posté par Unixfix le Gaulois . Évalué à 10.
[^] # Re: re
Posté par abramov_MS . Évalué à 0.
[^] # Re: re
Posté par Raphaël SurcouF (site web personnel) . Évalué à 6.
C'est fou le nombre de produits dont la durée de vie a chuté ces dernières années...
J'ai un vieux réfrigirateur qui doit avoir 20 ans et j'ai juste remplacé son ampoule. Prenons une machine à laver récente : au bout de deux ans, elle commence déjà à montrer des signes de fatigue. Ça tombe bien, la garantie a justement expiré...
[^] # Re: re
Posté par totof2000 . Évalué à 10.
A force de vouloir payer de moins en moins cher, faut pas s'étonner. Les tests de fiabilité et de longévité, ca coute. Si un constructeur garantit son lave-linge 2 ans, c'est qu'il l'a testé pour qu'il dure 2 ans sans problème (après, si t'as de la chance ça passe, sinon ....). Autre détail, autrefois les machines ne tournaient pas à plus de 1000 tr/mn, et qui dit vitesse plus élevée dit usure plus rapide des roulements .....
[^] # Re: re
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
[^] # Re: re
Posté par totof2000 . Évalué à 4.
# Et ben...
Posté par ethtezahl . Évalué à 1.
Rhaaa! Pourquoi on est pas Vendredi?
# laptop mode
Posté par gronk34t . Évalué à 10.
le problème le plus souvent identifié est le vm/dirty_expire_centisecs et vm/dirty_writeback_centisecs qui sont, par défaut dans le noyau, "juste trop court' pour être adapté aux valeurs par défaut des disques de laptop pour le déchargement des têtes (unload). Du coup, à chaque écriture, le disque décharge les têtes 2 fois.
Justement, laptop_mode est un des paramètres qu'il est fort utile d'activer, même en étant sur secteur : En augmentant la durée cache en écriture, et en groupant les écritures juste après les lectures, il permet de réduire significativement le nombre d'accès en écriture et, de là, le nombre de cycles de chargement/déchargement des têtes.
Reste le paramètre d'économie d'énergie des disques, qu'on peut régler sur -B255 sur secteur, mais ce n'est pas le paramètre le plus significatif, sauf à aller vers des valeurs extrème style -B1 !!
# unixfix travaillerait pour Paris Match ?
Posté par paul . Évalué à 10.
On peut noter également que depuis des années les thinkpads et les macbooks sont équipés d'accéléromètres qui déclenchent le rangement des têtes dès que l'ordinateur bouge. Pourquoi ne pas les attaquer eux aussi ?
En plus, tu fais presque dire au mainteneur que 11 mois de durée de vie sont suffisants. La réalité, c'est qu'un gugus a lancé SMART sur son hdd et a constaté beaucoup de cycles de rangement des têtes, puis il a fait sa régle de 3 avec les données d'une doc qu'il a dégoté et il dit que si ça continue comme ça son disque va tenir 11 mois. C'est pas tout à fait la même chose. Pour conclure le ton du lien fournit est risible, pourquoi ne pas fournir directement les liens vers les bugs confirmés ? Une mise a jour qui va changer ce comportement est peut-être en prévision, c'est bien peu de chose à faire, et si la communauté préfère c'est ce qu'il vont faire. Reste à attendre le prochain journal : "Cannonical aurait des actions chez les fabricants de batterie !" qui pointera vers un lien se plaignant de la surconsommation du portable depuis la dernière mise à jour :)
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par briaeros007 . Évalué à 10.
Parce que ranger les têtes une fois par minutes, désolé de te décevoir mais ce n'est PAS ce pour quoi le matos a été conçu.
Compromis entre performance et durée de vie.
Sinon je suis capable de te faire un portable hyper performant tant d'un point de vue calcul brute et rapport performancecalcul/consommation mais qui a une durée de vie de 0.2 seconde.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 10.
Je suis un "gugusse" qui vient de constater 86000 cycles de rangement des têtes sur son portable (en quelques mois). Quand je l'ai acheté, la première remarque que je me suis fait, c'était justement ce bruit du DD bien gênant. J'ai mis ça sur le compte du matériel, grossière erreur de ma part. Pour le coup, je regrette de n'avoir pas booté une seule fois sur le windows.
Quand tu dis "tu actives le laptop-mode", c'est faux. Je n'ai rien activé du tout, c'est activé par défaut par Ubuntu. Assimiler ce comportement du disque dur à une économie d'énergie, c'est comme dire que mettre de l'éther dans ton réservoir, ça fait une économie d'essence. Une fois ton moteur cramé, tu as l'air malin - sans compter la nuisance sonore, plusieurs fois par minute "cric cric", ça gave.
Donc je ne remercie pas Ubuntu pour traîner à corriger ça, ça fait plus d'un an que ça dure visiblement. Par contre je remercie l'auteur du journal pour cette information, ça va sans doute prolonger la durée de vie de mon disque dur, et mes oreilles sont enchantées.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Unixfix le Gaulois . Évalué à 4.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 5.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 6.
Donc le problème existe et à mon sens Ubuntu est responsable. Ca ne sert à rien de se cacher derrière une mauvaise config du bios ou du DD, je ne vois pas pourquoi le hdparm -B n'est pas à 255 par défaut pour protéger le matériel. Là, je suis sous Feisty, et le même problème existait déjà sous Edgy, Dapper...
J'ai l'impression que, parce que le gars qui a écrit l'article est un anti-Ubuntu, certains minimisent le problème. Je suis pro-Ubuntu, mais là, désolé les gars, mon expérience me laisse penser qu'il a raison sur ce point.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par abramov_MS . Évalué à -3.
Quoiqu'il en soit par default Ubuntu n'a pas le comportement tel que decrit dans l'article point barre donc le probleme il ne vient pas d'ubuntu (vu que tout pour ne pas l'avoir est present) mais de l'interface chaise-clavier qui veut jouer au roi des geeks. En gros on a droit a une belle arrive des script-kiddies sous linux!
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 4.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par abramov_MS . Évalué à 2.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 3.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par abramov_MS . Évalué à 1.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 3.
Qu'est-ce qui est le plus dur, écrire un pilote d'imprimante, ou récupérer une chaîne de caractères correspondant à un modèle de disque dur, et changer un paramètre selon sa valeur ?
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Anonyme . Évalué à 1.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 0.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par abramov_MS . Évalué à 2.
- tu as bien envoye a ubuntu la liste du matos que tu as? Il existe une possibilite pour faire cela (je te laisse chercher la commande je l'ai personnelement fait il y a 1 an).
- tu as rempli un bug report, ou mis ta contribution a ceux deja signale?
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 3.
- non, et je ne pense pas qu'il soit utile de le faire, car j'ai le même DD qu'un DD qui a été signalé dans un rapport de bug.
- https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/(...)
- inutile de jouer à celui qui a la plus grosse contribution. Le problème, ce n'est visiblement pas un manque de contributions, mais la décision de certains devs de ne pas modifier le comportement actuel.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par abramov_MS . Évalué à -4.
Donc tu as un probleme et tu refuses de donner la mondre information relevante sur le sujet et tu preferes taper sur linux et les distributions linux de facon totalement gratuite et inutile (vu que le probleme n'en est pas un et qu'il existe deja des facons de le coutourner).
Ton comportement me derange pas mal car tu te permets de critiquer, de crier au scandale mais par contre des qu'il est question de fournir des informations et c'est tout de meme le minimum d'aide que l'on peut fournir dans le cadre d'un projet communautaire, il n'y a plus personne.
En resume on a vraiment l'impression que tu voudrais un systeme parfait, gratuit, qui lise dans tes pensees et te fasses le cafe en prime voir te file du fric? Si vraiment cela te gene de mettre les mains dans le cambouis (editer deux fichiers cela semble etre trop difficile) il faut changer de systeme et passer sous OSX ou sous Windows.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 3.
Oui, ça me gène qu'il faille éditer 2 fichiers. On ne peut pas prétendre que Ubuntu est une distro pour Mme Michu, et demander à Mme Michu d'éditer des fichiers de conf pour que son DD ne claque pas. Pour info, j'ai déjà installé 2 Ubuntus à des Mme Michu, et ça me gave d'avoir à régler ça.
Quant à vouloir m'envoyer sur Windows, tu devrais lire http://linuxfr.org/comments/877493.html#877493 bien que je doute que ton esprit manichéen puisse adhérer à ce propos. Et si Ubuntu a trop de problèmes de stabilité ou d'impact sur le hardware, je retournerai plutôt chez Debian qui a une bien meilleure politique de ce côté. Bon, maintenant, j'arrête de nourrir le troll.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par abramov_MS . Évalué à -5.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par abramov_MS . Évalué à -1.
http://www.ubuntu.com/community/conduct
De plus si tu lis les commentaires tu verras que tu ne devrais surtout pas utiliser MacOS car c'est exactement la meme chose que sous linux... Donc ton choix se limite a utiliser Windows! Bon courage il parait qu'ils ont un super systeme qui s'appelle Vista. <mode ironique>Il est super bien, intuitif, avec plein de drivers et tous ses utilisateurs l'adorent.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
Je dois vivre dans une réalité alternative à la tienne.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 2.
Prend les imprimantes dans la colonne de droite, et n'oublie pas de pondérer par le nombre d'imprimantes vendues. Tu verras que la réalité n'est pas si noire, grâce au travail de la communauté.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par lezardbreton . Évalué à 2.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par lezardbreton . Évalué à 5.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par djibb (site web personnel) . Évalué à 5.
Comme quoi... l'image de marque.......
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par paul . Évalué à 10.
- une utilisation excessive de la fonction de rangement des tête abîme le disque dur, je te l'accorde
- une valeur de 255 signifie une desactivation complète de l'APM du disque dur. Difficile pour un mainteneur d'un paquet de gestion globale de l'énergie, de justifier un tel paramêtre
- des articles fusent de tout part, criant au loup, certains sur des tons vraiment surprenant (béranger je parle encore de toi), et accusant ubuntu et en particulier son mainteneur de LAPTOP-MODE, l'incriminé. Tu as aussi réagi ainsi un peu plus haut. Résultat des courses, tu viens de dire que laptop-mode est off chez toi et que tu avais le problème.
Évitons le FUD, et évitons l'archarnement qui donne dans le sensationnalisme.
Pour information, j'ai eu le problème du cliqueti sur un thinkpad il y a plus de 2 ans de ça, c'était pas sur une ubuntu à l'époque. L'instruction qui range les têtes peut venir du noyau ou du bios, pour t'en convaincre demande toi qui range ces têtes à l'extinction de la machine. Sur mon thinkpad, j'ai un bout de 50 lignes de C qui envoie ce qu'il faut pour parker les têtes du disque, j'ai pris ça dans un module du noyau y'a 2 ans. Aujourd'hui, il me semble qu'il y a des projets comme hdaps_protect qui ouvre une interface dans le sysfs pour parker les têtes du disque. Si tu installes ça et que tu envoies ce qu'il faut dans l'interface, les têtes vont se parker et tu vas pouvoir vérifier que c'est bien ce bruit que tu entends tout le temps. Bonne chance.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 7.
Passer ce paramètre à 255 est pour moi totalement justifié, tant qu'on n'a pas de moyen sûr d'éviter ce phénomène. Peu de voitures auraient un pot catalytique si ça envoyait un véhicule sur 50 dans le décor (même avec un véhicule sur 5000).
Je me fiche que le coupable soit le laptop-mode, le bios, le noyau ou obiwan kenobi. Ubuntu a au moins un moyen d'empêcher ce comportement : passer le paramètre à 255. Qu'il le fasse, après, on essaiera de raffiner pour réactiver l'apm si possible.
Non, vraiment, je ne comprends pas qu'on fasse passer l'économie d'énergie avant la sécurité du matériel. Et ceux qui disent qu'on peut bien accepter de claquer un disque dur de temps en temps, du moment que la batterie tient plus longtemps, sont soit de mauvaise foi, soit irresponsables.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à -2.
L'irresponsabilité est de ne pas avoir de sauvegardes. J'imagine que c'est en partie pour cela que tu es en colère.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 3.
Et s/Ubuntu/Les distributions Linux/ si tu veux. J'ai vu que d'autres avaient le même problème avec Mandriva, alors bouuuh Mandriva.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 5.
Quand je vois depuis combien de temps le problème dure, alors qu'il est identifié et qu'on sait le corriger, ça me gave.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par inico (site web personnel) . Évalué à 1.
Ce qui pour un portable fais vite baisser l'autonomie.
Et on aurait eu: « Ubuntu ca sux ! Je n'ai que 1H d'automonie alors que [distrib_X] a une automonie de 3h !».
Tu prefere une autonomie minable ou un disque qui risque de s'user un peu plus vite ?
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Putifuto . Évalué à 10.
Parce que sans disque dur, l'autonomie est de 0 secondes.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par SKBo . Évalué à 2.
Bon par contre, on ira jamais plus loin que le POST, mais c'est pas bien méchant au vu des économiques immenses que l'on réalise comme cela.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par inico (site web personnel) . Évalué à 1.
Et ca fonctionne bien.
Faudrait juste que je trouve le temps de compiler un kernel avec kexec histoire de pouvoir patcher le kernel :)
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par FreeB5D . Évalué à 2.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 7.
Dans ma société, nous sommes tous ou presque équipés avec des portables Dell D800 ou D810. Tu crois franchement qu'on n'aurait pas remarqué qu'Ubuntu réduirait singulièrement la durée de vie des disques durs ? Or, depuis au moins deux ans, de nombreux collaborateurs ainsi que moi-même utilisons Ubuntu.
Accuser le seul éditeur du système alors qu'il y a vraisemblablement une corrélation entre le matériel et, sans doute, le logiciel, c'est vraiment se foutre de la gueule du monde.
Quant à l'auteur de l'article, s'il en avait écrit de meilleurs, l'avis de certains aurait été sans doute différent à son crédit. Mais ce n'est pas le cas.
Pour finir, qui nous dit que tu n'auras pas de nouveau (parce que j'imagine que tu viens de racheter ton disque dur) un problème dans quelques mois ?
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par gnujsa . Évalué à 1.
> depuis au moins deux ans, de nombreux collaborateurs ainsi que moi-même utilisons Ubuntu.
Profitez bien de vos disques, il vous reste encore 6 mois ;-)
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Beurt . Évalué à 3.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 1.
smartctl -d ata -a /dev/hda
193 Load_Cycle_Count 0x0012 092 092 000 Old_age Always - 86571
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par liberforce (site web personnel) . Évalué à 2.
Est-ce que le résultat est dépendant de la data d'installation des smartmontools ? Parce qu'ils ne sont pas installés par défaut...
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 1.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par herodiade . Évalué à 3.
193 Load_Cycle_Count 0x0032 075 075 000 Old_age Always - 2563793638660
2563793638660 cycles de parquages de têtes sur mon HITACHI_DK13FA-40B (disque par défaut dans mon IBM Thinkpad X40) ?
Super fiable...
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 2.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par liberforce (site web personnel) . Évalué à 2.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Lapinot (site web personnel) . Évalué à 4.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par liberforce (site web personnel) . Évalué à 3.
Mandriva 2007.1 sur un portable Compaq nx9105, qui a 3 ans, mais que j'utilise sous Linux depuis à peine plus d'un an. Ça fait quand même 134 fois plus que sur un desktop du même âge.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par allcolor (site web personnel) . Évalué à 1.
Sur mes 3 disques... Mon ordinateur est un pc de bureau... C'est normal le 0 ?
J'ai ceci qui me laisse penser que oui mais..
Donc ça veut vraiment dire kekchose ce "Load_Cycle_Count" ? je précise aussi que je suis sous ubuntu depuis breezy donc 2 ans.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par ccomb (site web personnel) . Évalué à 3.
Par contre (j'ai lu que) c'est la journalisation ext3 qui fait ça.
Le laptop mode permet justement d'éviter cette activité (quitte à perdre des données en cas de coupure brusque, mais bon y a la batterie). Et du coup je l'ai activé par défaut, même sur secteur.
Mauvais choix, : Load_Cycle_Count 240434 en 1 an...
Mais c'est vrai que c'est gonflant de voir la diode s'allumer régulièrement...
Donc -> laptop mode toujours, mais -B 255.
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par Antoine . Évalué à 2.
Par défaut le flush du journal a lieu toutes les 5 secondes en effet. Mais ça n'arrive que si tu écris des données sur le disque dur.
# Oui mais...
Posté par Smarter . Évalué à 9.
[^] # Re: Oui mais...
Posté par Unixfix le Gaulois . Évalué à 3.
Jouer avec hdparam est au-dela des compétence de l'utilisateur ciblé par Ubuntu.
Mais après tout cela ne fait que 6 mois que le probème existe donc les problèmes sont encore à venir.....
Celà étant le Power management a toujours été un problèmes et visiblement si les problèmes d'hibernation sont à peu près résolus il y a encore des pièges.
Il serait bon qu'Ubuntu annonce que LAPTOP_MODE est une arme à double tranchant....
[^] # Re: Oui mais...
Posté par Smarter . Évalué à 10.
A ma connaissance, le seul moyen d'activer le laptop mode est de modifier la variable ENABLE_LAPTOP_MODE dans /etc/default/acpi-support , donc l'utilisateur qui va jusque là il est forcément un peu geek ;) et le commentaire au dessus de la variable dit que ça peut poser problème
[^] # Re: Oui mais...
Posté par abramov_MS . Évalué à 5.
# Switch to laptop-mode on battery power - off by default as it causes odd
# hangs on some machines
ENABLE_LAPTOP_MODE=false
si oui c'est exactement ce qui est fait!
[^] # Re: Oui mais...
Posté par Antoine . Évalué à 2.
# hangs on some machines
ENABLE_LAPTOP_MODE=false
"odd hangs" ("plantages bizarres") ce n'est pas la même chose que "va réduire énormément la durée de vie de votre disque dur". L'utilisateur qui lit ce message se dira que s'il ne constate pas les dits "plantages bizarres", alors tout va bien et il n'y a rien à craindre.
# confus pour moi
Posté par Putifuto . Évalué à 10.
Reprenons, donc, sur mon portable
Si grep ENABLE_LAPTOP_MODE /etc/default/acpi-support
renvoi quelque chose, c'est que je peux avoir le problème.
un hdparm -B 255 /dev/sda corrige le problème.
Faut-il rajouter ça dans un rc.local ou pas?
Comment vérifier la valeur actuelle ?
Eventuellement, vm/dirty_expire_centisecs et vm/dirty_writeback_centisecs peuvent poser problème. Comment savoir les valeurs à mettre ? et comment rendre ses changement permanents?
Désolé de ces questions un peu connes. Mais, j'essaie juste de comprendre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: confus pour moi
Posté par gronk34t . Évalué à 10.
Pour commencer, que signifie décharger les têtes ? C'est les déplacer hors de la surface du disque pour 1. économiser l'énergie du système de positionnement de têtes et 2. mettre le disque en sécurité lors de chocs/vibrations de moyenne importance. En ce sens, cela ressemble un peu au parquage des têtes à l'arrêt du disque mais, disons, dans une moindre mesure. De ce fait, le déchargement des têtes d'un disque de laptop est beaucoup plus rapide que celui d'un desktop. Ce temps est géré directement par le firmware du disque et, selon les modèles, on a un peu d'influence dessus via le paramètre -B de hdparm, ou pas du tout. Tout dépends du constructeur.
L'autre pendant du problème est le mécanisme de cache en écriture du noyau, qui (sans que je sache expliquer dans le détail) n'écrit pas tout d'un coup sur le disque, mais grosso-modo, en deux fois. Ceci est parfairement visible avec un utilitaire comme gkrellm qui permet de tracer les accès disque. Avec les valeurs par défauts, on constate donc la séquence suivante lors d'une écriture peu importante :
- Chargement de la tête
- Ecriture
- Déchargement de la tête
- Chargement de la tête
- Vidage du cache
- Déchargement de la tête
Attention, contrairement a ce que laisse croire le troll, ceci se produit indépendamment de l'activation du laptop_mode !!
C'est évidement contre-productif. La solution contre ça est de jouer sur les paramètres vm/dirty_expire_centisecs et vm/dirty_writeback_centisecs qui permettent, au choix de raccourcir le délai entre l'écriture et le vidage du cache, soir au contraire, de tolérer un cache très long. Je suis en partisan des caches très long sur les laptops : Pas de risque de coupure de courant, et une fois tous les drivers bien optimisés, les plantages hard sont très rare. Donc, je prends le risque et j'utilise 1h (oui, vous avez bien lu !), ie vm/dirty_expire_centisecs=vm/dirty_writeback_centisecs=360000. Bon, c'est un réglage extrème, 5 ou 10minutes sont très bien aussi, hein ;)
Ensuite, le laptop_mode aide bien en la matière, car il permet de grouper les accès en écriture juste après que le disque ait été réveillé (s'il était en veille) par un accès en lecture. Donc laptop_mode + long cache en écriture + gros cache en lecture = on travaille quasiment qu'en RAM, avec des gains de rapidité importants en plus des gains d'autonomie sur batterie.
En pratique, je préconise l'installation de laptop_mode, et tous les réglages se font dans /etc/laptop-mode/laptop-mode.conf. Voici les réglages clef que j'utilise :
ENABLE_LAPTOP_MODE_ON_BATTERY=1
ENABLE_LAPTOP_MODE_ON_AC=1
ENABLE_LAPTOP_MODE_WHEN_LID_CLOSED=1
Au diable les compromis !!
MINIMUM_BATTERY_CHARGE_PERCENT=3
DISABLE_LAPTOP_MODE_ON_CRITICAL_BATTERY_LEVEL=1
Ça, c'est pour se pouvoir dépécher de vider le cache en écriture quand la batterie est presque à plat
LM_BATT_MAX_LOST_WORK_SECONDS=3600
LM_AC_MAX_LOST_WORK_SECONDS=3600
C'est ce paramètre qui va fixer les vm/dirty_machins via le script de laptop_mode
CONTROL_HD_IDLE_TIMEOUT=1
LM_AC_HD_IDLE_TIMEOUT_SECONDS=300
LM_BATT_HD_IDLE_TIMEOUT_SECONDS=20
Les temps mise en veille du disque (arrêt rotation)
CONTROL_HD_POWERMGMT=1
BATT_HD_POWERMGMT=1
LM_AC_HD_POWERMGMT=255
NOLM_AC_HD_POWERMGMT=255
Contrôle le paramètre -B de hdparm : 255 si secteur, 1 si batterie. En mode 1, le disque s'arrête après seulement quelques secondes d'activité ! A n'utiliser qu'en connaissance de cause !
CONTROL_HD_WRITECACHE=1
NOLM_AC_HD_WRITECACHE=0
NOLM_BATT_HD_WRITECACHE=0
LM_HD_WRITECACHE=1
On active le cache en écriture si laptop mode est actif, on le désactive sinon. Utilisé en combinaison avec la désactivation auto si <3% de batterie pour vider les caches avant la panne sèche
Voilà, c'est tout pour la partie HDD de laptop_mode.
Ensuite, pour gagner encore plus en autonomie batterie ainsi qu'en durée de vie du hdd, je minimise les écriture sur disque en :
- montant /tmp en ram (tmpfs)
- liant /var/tmp et ~/tmp vers /tmp
- plançant dans ~/tmp les répertoires gconfd-user, kdecache-user, kde-user, ksocket-... etc, bref tout les trucs qui ne nécessitent pas vraiment de se conserver d'une session à l'autre, et qui génère bcp de traffic en écriture.
Voilà voilà ! En retour d'expérience, mon précédent laptop (machine principale de travail) a fonctionné 14000h en 5ans, et j'ai "usé" 1,5 hdd : Le 1er changé préventivement au bout de 4ans après qu'il ait atteint sa limite de design pour le load/unload cycle, le deuxième est toujours en service !
Merci a ceux qui m'ont lu jusqu'au bout !!
[^] # Re: confus pour moi
Posté par Putifuto . Évalué à 9.
Merci à toi pour cette excellent tuto. en rentrant ce soir, je vérifie mes paramètres :-)
[^] # Re: confus pour moi
Posté par mats . Évalué à 4.
C'est donc moi qui te remercie.
Bye
[^] # Re: confus pour moi
Posté par herodiade . Évalué à 10.
Par rapport à la dépêche, il faut quand même rappeler que les têtes font un cycle load/unload si vous passez de l'activité disque à l'inactivité, puis à nouveau à l'activité, etc... en permanence. Si vous restez en activité continue, les têtes ne sont pas parquées, et si l'activité disque est bien réduite, les têtes restent parquées : dans les deux cas, le nombre de load/unload n'augmente pas.
Si les accès disques ont seulement lieu lorsque vous travaillez réellement dessus (ie. lecture d'une vidéo stockée sur le disque), et s'ils sont au repos lorsque vous ne faite quasiment rien d'autre (lire une page web, etc.), alors les têtes resteront parquées plus longtemps avec un x ("hdparm -B x") faible.
Or précisément, le laptop_mode (le mode dont on parle, qui exécute le "hdparm -B 1") vise à réduire le plus possible les activités disques non d'arrière-plan (et à regrouper les autres, etc.). Bref, le laptop_mode permet effectivement de ne pas augmenter le cycle load/unload, en restant plus longtemps avec les têtes parquées.
Précisons aussi que sous Ubuntu, le kernel est patché pour que les partitions soient montées en noatime par défaut (ce qui réduit là encore considérablement les accès hors du cache). Si vous utilisez une autre distro sur un laptop, faites un "mount -o remount,noatime /" (ou mieux, ajustes votre fstab). Aussi, le fichier de configuration /etc/laptop-mode/laptop-mode.conf (si le paquet laptop-mode est installé) permet de passer une configuration alternative à syslogd lorsqu'on est sur batterie (ie. n'écrire sur le disque que les messages critiques ou emergency, et ne flusher que rarement).
Une configuration correcte et propre, par une distribution Linux responsable, des ordinateurs portables lorsqu'ils sont sur batterie ne consiste pas à coller un hdparm conservatif (style -B 255) « et basta, on se mouille pas les mains et osef de la consommation », mais bel et bien à réduire le plus possible les accès disques inutiles (réduire le nombre de cycles load/unload en privilégiant la stagnation dans l'état "têtes parquées" et pas en privilégiant l'état "têtes actives") : c'est ça, la solution propre, à viser.
Donc oui, Matthieu Garett à raison de préciser que cette valeur d'hdparm est activée par Ubuntu seulement lorsque le laptop_mode est activé : car dans ce cas, le risque d'impact sur la durée de vie est minimisé. Et il a aussi raison de pester contre les fabriquant de disque qui mettent des valeurs très courtes par défaut : car elle seront actives telles quelles, même lorsque vous n'êtes pas en mode laptop.
nb: par contre il y a un bug d'Ubuntu qui fait que on_ac_power(1) retourne parfois 0 même sur des desktop branchés sur le secteur, et ça c'est plus embêtant.
[^] # Re: confus pour moi
Posté par abramov_MS . Évalué à 6.
LM_BATT_MAX_LOST_WORK_SECONDS
LM_AC_MAX_LOST_WORK_SECONDS
et par defaut ubuntu les a regle a 10 et 5 minutes comme tu le conseils... Donc celui qui choisi d'utiliser laptop-mode a deja les bonnes valeurs.
[^] # Re: confus pour moi
Posté par gronk34t . Évalué à 3.
Petit résumé des noms de variables :
LM_BATT_* : Laptop mode activé et sur batterie
LM_AC_* : Laptop mode activé et sur secteur
NOLM_BATT_* : Laptop mode désactivé et sur batterie
NOLM_AC_* : Laptop mode desactivé et sur secteur
A noter qu'on est toujours désactivé si laptop_mode n'est pas installé ; mais qu'on peut être activé ou désactivé s'il est installé et lancé : tout dépends des conditions que l'on précise en début du fichier de conf
[^] # Re: confus pour moi
Posté par ccomb (site web personnel) . Évalué à 0.
BATT_HD_POWERMGMT=1
C'est justement là qu'est tout le probleme.
Il vaut mieux mettre 254 ou 255.
Je faisais comme toi, mais depuis 1 an le load cycle est à 240 000 sur mon portable. (Alors qu'il est à 300 sur un fixe)
Donc je conseille de garder le laptop_mode, mais de passer l'apm en 255. Ton expérience prouve seulement que tu as eu de la chance, mais n'a malheureusement aucune valeur statistique.
[^] # Re: confus pour moi
Posté par gronk34t . Évalué à 5.
C'est clair ! Je n'ai jamais prétendu autre chose !! Elle a au moins le mérite d'offrir un peu plus de recul que ce que j'ai pu lire jusqu'à présent.
"Ton expérience prouve seulement que tu as eu de la chance, [...]"
Là, je ne suis pas d'accord ! Si tu lis une ligne plus loin, tu verra que je suis en 255 sur secteur, ce qui constitue 99% de mon utilisation du PC ! Le B1 n'est utilisé que sur batterie, et j'utilise la batterie :
- comme UPS ;)
- dans le train ou l'avion. Et là, avec les vibrations et les secousses, je suis rassuré de savoir mon disque arrêté quasiment en permanence !
L'autre chose qui est claire, c'est que le load/unload d'un portable ne sera jamais aussi faible que celui d'un desktop. Et l'il l'était, la surface du disque serait détruite par les vibrations bien avant de l'être par le nombre de déchargement de tête !
[^] # Re: confus pour moi
Posté par ccomb (site web personnel) . Évalué à 2.
[^] # Re: confus pour moi
Posté par anakin . Évalué à 1.
Merci
# Beranger.org est il encore crédible ?
Posté par liberforce (site web personnel) . Évalué à 10.
http://www.beranger.org/index.php?page=diary&2007/10/24/(...)
Mathew Garett démontre dans son blog qu'en fait tout ce que fait Ubuntu c'est se fier par défaut aux paramètres de gestion d'énergie du BIOS, et que le comportement extrême peut, il est vrai, survenir en laptop_mode. Ubuntu n'est pas réellement en cause, mais le BIOS oui. Beranger.org est donc aux fraises.
http://www.advogato.org/person/mjg59/diary/82.html
Il y a quelques jours, le sombre individu hurlait à l'obscurantisme sur la politique de sécurité de Mandriva.
http://beranger.org/index.php?page=diary&2007/10/19/12/3(...)
Vincent Danen, chagé des mises à jour de sécurité chez Mandriva, a démonté ses arguments sur son blog.
http://linsec.ca/blog/?p=144
Bref, ce béranger donne dans le sensationnalisme, et je ne pense pas que ses articles foireux méritent des journaux de première page ici...
Bon, un bon point quand même, parce qu'Il aime les tristus et les rigolus. Et moi aussi.
http://www.beranger.org/index.php?page=about
[^] # Re: Beranger.org est il encore crédible ?
Posté par Unixfix le Gaulois . Évalué à 2.
Ce qui me gène dans ce cas précis c'est la réponse du mainteneur qui avoue certes qu'il y a un problème mais en minimise les conséquences et estime qu'il n'y a pas urgence….
Cependant il ne faut pas oublier qu'Ubuntu est un fournisseur OEM de DELL entre autres. DELL vend des Notebooks donc si effectivement il y a de la casse bonjour les dégats pour Ubuntu, Linux et le libre en général…..
[^] # Re: Beranger.org est il encore crédible ?
Posté par gnumdk (site web personnel) . Évalué à 7.
[^] # Re: Beranger.org est il encore crédible ?
Posté par Gniarf . Évalué à 3.
[^] # Re: Beranger.org est il encore crédible ?
Posté par brunus (site web personnel) . Évalué à 5.
"Now that I know you're not an Ubuntu user, the included [README|] tells you all about what to do."
Tiens je vais stigmatiser aussi... :
Et bhé ! Heureusement que je suis un lecteur de beranger.org hein ! Je saurais pas pas comment me débrouillé tout seul avec mon Solaris si le maître vénéré n'avait pas posté quelques captures-d'écran explicites !
[^] # Re: Beranger.org est il encore crédible ?
Posté par beranger . Évalué à 0.
[^] # Re: Beranger.org est il encore crédible ?
Posté par beranger . Évalué à 2.
On a sur Launchpad deux bogues sur la vie des disques durs, et que fait Canonical ? RIEN ! C'est seulement après mon billet que Mathew Garett juge utile de démentir quoi que ce soit. Comme quoi, ceux qui ont commenté sur les deux bogues sont des idiots, et signaler une bogue est complètement inutile, hein ?
Soit Ubuntu ne change rien d'essentiel sur un portable et c'est "presque toujours" la faute au BIOS (mais je le doute très fort), soit il le fait, mais alors il faudrait : (1) soit expliquer ça dans les deux bogues sur Launchpad ; (2) soit ajouter une option (et un outil graphique) qui permettrait à Jean Dupont de dire "non, j'veux pas cette politique avec le MODE_LAPTOP, mais une autre, plus gentille avec mon disque dur".
Quant à la sécurité de Mandriva, j'ai repris ce que Susan Linton de Tuxmachies a cru comprendre : que Mandriva livrerait une version de Oo.org vulnérable. Si Susan et moi sommes tombés dans l'erreur, pensez encore à ce pauvre Monsieur Durand qui n'a aucun indice, car le label est bien "2.2.1" (en tout), et alors avant qu'on me crucifie, il faut faire quelque chose pour que les utilisateurs cible de Mandriva sachent exactement de quoi s'agit-il.
Je rends un service public, les potes ! :-)
[^] # Re: Beranger.org est il encore crédible ?
Posté par liberforce (site web personnel) . Évalué à 10.
Euh, comme poser la question aux principaux intéressés, tu veux dire ? Ou à n'importe quel utilisateur averti ? Pour le reste, je te concède le coup du laptop_mode, mais tant que tu auras des réactions du type:
...je me permettrai de douter de ton objectivité. Je trouve cela malheureux que tu surfes sur la vague du sensationnalisme.
[^] # Re: Beranger.org est il encore crédible ?
Posté par Putifuto . Évalué à 7.
[^] # Re: Beranger.org est il encore crédible ?
Posté par pampryl . Évalué à 4.
Ce qui n'est pas forcément le signe d'une grande crédibilité ou d'un réel sens de la vérification en soi...
beranger:
Tu extrapôles un peu dans le sens qui t'arranges. Il explique juste SON point de vue sur la situation et signale le comportement par défaut de la distrib pour laquelle il contribue.
Matthew Garrett :
Maintenant, ceux qui sortent des chemins battus, doivent en assumer toutes les conséquences et surtout ne pas venir se plaindre de ne pas maitriser complêtement ce qu'ILS font... (à tous ceux qui se plaignent de ne pas avoir compris qu'activer ce mode n'était pas sans risque. )
beranger:
Et ça va les chevilles? Non mais sérieusement, ce genre de news très orientée et même pas pondérée ne mérite aucunement la mention de "service" et ce n'est sûrement pas à toi que s'adresserait le "public" moyen. Parler de "service public" alors qu'on est incapable de faire preuve de neutralité dans un post me semble un petit peu capilotracté voir carrément relever de la vantardise et de l'autoproclamation.
[^] # Re: Beranger.org est il encore crédible ?
Posté par satan . Évalué à 10.
Souvent on accuse les constructeurs de matériel de faire du matériel pour windows et c'est pour ça qu'il y a parfois des glitchs sous d'autres OS. En réalité, ce n'est pas du matériel fait pour windows, c'est windows qui a été adapté au matériel. Je vous conseille de lire le blog de Raymond Chen qui dévoile une partie du lourd travail fait chez Microsoft pour s'assurer de la compatibilité du matériel, même le plus pourri, avec Windows.
http://blogs.msdn.com/oldnewthing/archive/2003/08/28/54719.a(...)
Hardware backwards compatibility
Backwards compatibility applies not only to software. It also applies to hardware. And when hardware goes bad, the software usually takes the blame.
The HLT instruction tells the CPU to shut itself down until the next hardware interrupt. This is a big win on laptops since it reduces power consumption and thereby saves your lap from third-degree burns.
We (well, specifically, Jeff) had this implemented and working in Windows 95 but discovered to our dismay that there were many laptops (some from a major manufacturer) which would lock up unrecoverably if you issued a HLT instruction.
So we had to back it out.
Then the aftermarket HLT programs came out and people wrote, "Stupid Microsoft. Why did they leave this feature out of Windows." I had to sit quietly while people accused Microsoft of being stupid and/or lazy and/or selfish.
But now the statute of limitations has expired so at least I can say something (though I'm still not going to name that major manufacturer, nice try).
My favorite bad hardware, though, was a system which would crash if the video card was put in an expansion slot too far away from the power supply. Manufacturers will do anything to save a nickel.
And yet Windows 95 ran on almost all of this bad hardware. Why did we go to all this effort to accomodate bad hardware? Consider:
* You have a computer that works okay.
* You go to the store and buy Windows 95.
* You take it home and install it.
* Your computer crashes.
Whom do you blame? Hint: Not your computer manufacturer.
I have more hardware stories, but I have a meeting soon so I'll have to stop here for today.
Là où du matériel peut donc fonctionner correctement sous Windows, parce que sous linux on refuserait d'être prudent avec les données du BIOS pour la gestion de l'énergie il pourrait carrément perdre en durée de vie. Ca revient pas si cher la licence windows tout d'un coup.
Je pense qu'il est du rôle d'une distribution comme Ubuntu, qui prétends vouloir remplacer Windows (bug #1) et qui fait des deals OEM avec des géants comme Dell d'assumer un minimum de précaution avec le matériel du marché.
[^] # Re: Beranger.org est il encore crédible ?
Posté par Psychofox (Mastodon) . Évalué à 6.
c'est justement ce qu'ils font puisque le laptop-mode est désactivé par défaut.
# S*l*perie.......
Posté par fcartegnie . Évalué à 3.
En plus j'ai une série "defec-tueuse" non mentionnée précédemment:
TOSHIBA MK8025GAS
9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 1490
222 Loaded_Hours 0x0032 098 098 000 Old_age Always - 803
1490 heures, soit 62 jours
Et le chiffre qui fait peur:
193 Load_Cycle_Count 0x0032 091 091 000 Old_age Always - 97092
Donc si les toshiba (qui ne fournit pas ce type de donnees) on la même durée de vie que les hitachi, ce disque dure pas plus de 6 mois...
Et bien sur, AUCUN MOYEN de desactiver l'économie d'énergie.
Le HDPARM -B 255 fait rien, le 254 réduit a qq minutes le parcage.
[^] # Re: S*l*perie.......
Posté par sebmil . Évalué à 4.
J'ai acheté ce portable il y a 3 semaines et son compteur Load est à 2570 avant le début des tests (ce qui lui donnerait une durée de vie de 13 ans).
Les mesures sont effectuées sous Gutsy finale avec l'ordinateur totalement inactif, toutes mise en veilles et écran de veille désactivés.
La commande utilisée est :
while true; do smartstl -A /dev/sda | grep Load ; sleep <intervale> ; done
Par tranche de 1 minute : augmentation de 2 par tranche (soit 120 par heure)
Par tranche de 10 minutes : augmentation de 5 par tranche (soit 30 par heure)
Par tranche de 1 heure : augmentation de 10 par tranche (donc 10 par heure)
Le dernier relevé me ferait une durée de vie de 7 ans 24/24...
(Les autres ont plus d'opérations car ma boucle leur en fait faire régulièrement).
Pourtant les Thinkpad semblent être les plus affectés par ce problème, il faudrait vraiment trouver la corrélation système/BIOS/disque qui pose ce fameux problème pour donner une piste aux développeurs.
[^] # Re: S*l*perie.......
Posté par sebmil . Évalué à 5.
http://forum.ubuntu-fr.org/viewtopic.php?pid=1271796
Et de préciser que mon portable est un Thinkpad R61 et mon disque un Seagate ST9120822AS.
# Autodestruction
Posté par Arthur Accroc . Évalué à 4.
Même si ce n'est pas une fusée, compte tenu de son âge, il reste agréable à utiliser et suffisant pour ce que j'en fais, mais la question est qu'il reste en état de marche.
Je me doutais bien au bruit qu'il passait son temps à faire des parcages de tête, mais je n'avais pas pensé que leur nombre était limité. Il a atteint un highscore :
225 Load_Cycle_Count 0x0032 066 066 070 Old_age Always FAILING_NOW 349225
La question n'est même pas la distribution que j'utilise : il était déjà paramétré en hdparm -B 255, mais il s'en fiche complètement, il parque quand même les têtes au bout de juste quelques secondes !
Avec hdparm -B 254, cette fois, il prend le paramètre en compte et atteint la durée mirobolante d'une minute avant de parquer les têtes.
En conséquence, pour maximiser mes chances de faire durer le disque qui d'après smart est en train de tomber en panne, j'ai fait un script pour empêcher le parcage en forçant une activité disque une fois par minute.
Ça empêche toute mise en veille du disque, mais de toute façon, je ne l'utilise plus sur batterie depuis qu'il a décidé de tuer sa batterie en la chargeant par intermittences sans jamais la décharger...
Bon, si quelqu'un d'autre essaye de faire survivre un matériel conçu pour l'autodestruction, je peux éventuellement poster mon script.
En tout cas, l'info véritablement intéressante quand on achète (entre autres) un portable serait : est-il programmé spécifiquement pour s'autodétruire après un certain temps ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Autodestruction
Posté par Anonyme . Évalué à 1.
j'imagine que c'est un dd bien placé dans le cron combiné avec sync ?
tu aurais pus poster le script car il ne doit pas etre tres grand :)
[^] # Re: Autodestruction
Posté par GG (site web personnel) . Évalué à -1.
Une solution pour maintenir l'activité serait d'avoir des partitions en reiserfs (ou ext3), comme ça, toutes les 5 secondes... hop
D'ailleurs, c'est pour ça que ce type de partition n'est pas recommandé sur les portables :)
A bientôt
G
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Autodestruction
Posté par Gabriel Linder . Évalué à 3.
[^] # Mon script
Posté par Arthur Accroc . Évalué à 4.
Je veux pouvoir encore faire quelque chose avec ma machine ! :-)
Au début (j'ai fait des tests plus poussés après avoir écrit le script, justement en l'utilisant), je craignais de devoir activer le disque avec une périodicité inférieure à 10 secondes (ç'eût été le cas avec hdparm -B 255), donc cron était écarté d'office. De toute façon, je préfère avoir une granularité inférieure à une minute, et puis cron n'est pas sensé non plus garantir un déclenchement très précis.
Qui plus est, l'utilisation de cron pour une très faible périodicité conduit quelquefois en cas de forte charge système à l'accumulation d'appels.
Un simple sleep dans le script suffit à garantir un délai entre les opérations sans inconvénient.
Je n'étais pas trop chaud pour sync non plus, ayant l'expérience (avec le traitement massifs de mails par le serveur mail après rapatriement par uucp) de la charge système induite par des syncs fréquents (le serveur mail en fait un pour chaque mail).
Comme une écriture sans sync ne force pas d'activité disque, je me suis donc orienté vers une lecture (aléatoire pour essayer d'éviter de tomber sur des données en cache, doublée pour améliorer les chances).
En cas de forte charge en accès disque, logiquement ma demande de lecture doit attendre son tour comme les autres, ce qui tendrait à augmenter la périodicité dans une situation où l'opération est superflue. Tant mieux.
Par ailleurs, pour réduire le risque de délai supplémentaire inopportun au déclenchement en cas de très forte charge CPU, je voulais éviter tout chargement de contexte, donc tout appel d'une commande externe, donc je me suis dirigé vers une solution en Perl pur.
Bon, je ne prétends pas qu'il n'y aurait pas une meilleure solution (fsync, plus léger qu'un sync complet, serait une bonne piste; une lecture planifiée plutôt qu'aléatoire serait plus propre, mais nécessiterait des informations supplémentaires comme la quantité de données mise en cache à chaque accès disque), mais en tout cas, celle à laquelle j'ai abouti fonctionne de manière satisfaisante : pas d'augmentation du nombre de parquage des têtes après le démarrage, plus discrète que ne l'était le parquage, augmentation de la charge du système insensible.
Il n'est pas hyper petit non plus, vu qu'il contient en plus tout ce qu'il faut pour fonctionner comme un démon.
Enfin voilà :
--------
#!/usr/bin/perl -w
use strict;
# Lecture periodique sur le disque dur pour empecher le parquage des tetes
# alors que le nombre maximal prevu est deja explose depuis longtemps.
# Fonctionne comme un demon si son nom se termine par "d".
# Delai entre deux lectures, valeur a ajuster suivant le materiel.
# ATTENTION : une valeur incorrecte peut ACCELERER la deterioration du disque.
# Il est donc crucial de l'ajuster finement en controlant l'effet avec smartctl.
# La valeur presente dans /etc/sysconfig/no_park est prioritaire et les
# parametres passes en ligne de commande sont encore plus prioritaires.
my $delai = 60;
# Descripteur de peripherique du disque, valeur par defaut normalement ecrasee
# par celle determinee a partir de /etc/fstab.
my $disque = '/dev/hda';
use POSIX;
# Determination du peripherique
if (open FSTAB, '</etc/fstab') {
while (<FSTAB>) {
m:^(\S+?)\d+\s+/\s: and $disque = $1 and last;
}
close FSTAB;
}
# Determination du delai entre deux activations
if (open CONF, '</etc/sysconfig/no_park') {
while (<CONF>) {
/^\s*DELAI\s*=\s*(\d+)\s*(#|$)/ and $delai = $1;
}
close CONF;
}
# Prise en compte prioritaire des eventuels parametres de la ligne de commande
foreach (@ARGV) {
if (m:/:) {
$disque = $_;
} elsif (/^\d+$/) {
$delai = $_;
}
}
# Ouverture du disque en lecture
open DD, "<$disque" or die "Impossible d'ouvrir $disque\n";
# Fermeture du disque et sortie en cas de signal d'interruption
$SIG{TERM} = $SIG{INT} = sub {
close DD;
exit;
};
# Affichage des parametres retenus
warn "no_park : disque $disque, delai : $delai\n";
# Si le nom de commande se termine par "d", il s'agit du demon,
if ($0 =~ /d$/) {
# donc on detache le processus.
my $tent = 0;
DETACH:
if (my $pid = fork()) {
# Processus parent, on ferme.
close DD;
exit;
} elsif (!defined $pid) {
if ($! =~ /No more process/ && $tent++ < 5) {
# Erreur de fork eventuellement recuperable
sleep 5;
redo DETACH;
} else {
# Erreur de fork bizarre
die "Impossible de detacher le processus : $!\n";
}
}
# Processus fils
close STDIN;
close STDOUT;
close STDERR;
POSIX::setsid();
}
# Determination de la fin du disque
seek DD, 0, 2;
my $fin = tell(DD);
# Lecture periodique de donnees au hasard
my $tamp;
while (1) {
seek DD, rand($fin), 0;
read DD, $tamp, 1;
# Une deuxieme lecture pour limiter les risques de tomber sur un secteur en cache
seek DD, rand($fin), 0;
read DD, $tamp, 1;
# On laisse passer le delai entre deux activations.
sleep $delai;
}
----------
Note : si quelqu'un fait un copier-coller du code ci-dessus avec un navigateur qui conserve les espaces insécables à la copie (ce n'est pas le cas de Firefox), il aura intérêt à les enlever avec une commande du style :
sed -e 's/\xC2\?\xA0/ /' code_recupere.txt > /usr/local/sbin/no_parkd
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.