Journal Canonical aurait des actions de fabricants de disques durs!

Posté par .
Tags : aucun
0
25
oct.
2007
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.
  • # re

    Posté par (page perso) . Évalué à 7.

    C'est marrant j'en parlé hier avec mon collegue, comme quoi depuis 2 ans j'avais 2 fois de disque dur pour mon systeme... Ce texte apporte de l'eau a mon moulin ( ca fait 2 ans que j'utilise ubuntu a la place de mandriva )
    • [^] # Re: Dell va avoir des problèmes de garantie.....

      Posté par . Évalué à 10.

      Si les constatations sont vérifiées DELL va avoir de sérieux problèmes de garantie. J'espére pour eux que la version DELL d'ubuntu a été corrigées...
    • [^] # Re: re

      Posté par . Évalué à 0.

      sauf que comme dit partout le "probleme" n'existe pas et n'est pas installe par defaut donc il va falloir trouver une autre excuse. Moi je prone pour l'augmentation de la fragilite des DD avec l'augmentation de leur capacite et de leur rapidite.
      • [^] # Re: re

        Posté par (page perso) . Évalué à 6.

        Et l'augmentation de la rentabilité pour mieux garnir les poches des actionnaires.
        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 . Évalué à 10.

          Pour le lave-linge, faut bien le choisir.

          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 (page perso) . Évalué à 1.

            Oui mais des lave-linges à plus de 500¤, je n'ai pas envie d'en acheter tous les deux ans quand même.
            • [^] # Re: re

              Posté par . Évalué à 4.

              Ben celui la c pas 2 ans qu'il dure mais dix ... a coté de 200 euros tous les deux ans ....
  • # Et ben...

    Posté par . Évalué à 1.

    Ca ferait un joli troll

    Rhaaa! Pourquoi on est pas Vendredi?
  • # laptop mode

    Posté par . Évalué à 10.

    Ce problème n'est pas spécifique à canonical ! Ça fait déjà quelques années que j'ai pris l'habitude de régler les paramètres du hd sur toutes les distros que j'ai installé sur des laptops !

    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 . Évalué à 10.

    Ce genre de nouvelle n'a rien de sensationnel. Quand tu actives le laptop-mode, tu souhaites généralement une gestion poussée de la veille, c'est à dire que tu souhaites recourir aux moyens d'économie proposés par ton système. Tout le monde sait que les pieces mécaniques ont un nombre de cycles limités. Dans ce cas, ne ferme pas trop souvent le capot de ton portable, n'utilise pas ton lecteur de CD, ne mets pas le HDD en veille ... bref n'utilise pas ce pour quoi le materiel est vendu pour, et ça durera plus longtemps. Quel scoop.
    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 . Évalué à 10.

      le terme "compromis" tu connais ?
      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 (page perso) . Évalué à 10.

      N'importe quoi. Ca me désole que tu aies un 10, ça prouve qu'au moins 9 autres personnes ont cru ce que tu racontes.

      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 . Évalué à 4.

        Ce n'est pas moi qu'il faut remercier mais beranger. Je n'ai fait que rapporter ce que j'avais lu sur beranger.org.
      • [^] # Re: unixfix travaillerait pour Paris Match ?

        Posté par (page perso) . Évalué à 5.

        De ce que j'ai compris, il ya 2 moyens d'arriver au même problème: soit un BIOS pas super sympa envers ton disque, soit le laptop mode... ce dernier n'est effectivement pas activé par défaut justement à cause de défauts de ce genre... Moralité le commentaire du dessus a au moins à moitié autant raison que toi... Et tout ca n'est à priori pas de la faute de Ubuntu.
        • [^] # Re: unixfix travaillerait pour Paris Match ?

          Posté par (page perso) . Évalué à 6.

          Je n'ai pas encore fait le tour du problème : chez moi, ENABLE_LAPTOP_MODE est à false. On dit par ailleurs que ça devrait permettre d'éviter ce problème, or ce n'est pas le cas. Par contre lancer "hdparm -B 255 /dev/hda" arrête ce mauvais comportement du DD.

          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 . Évalué à -3.

            si tu configures laptop mode pour cela mais par defaut laptop mode n'est pas installe. Si tu veux le mettre en route tu es deja un utilisateur expert alors on attend aussi de toi que tu ailles dans le fichier de conf de laptop mode et choisir les options que tu veux.

            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 (page perso) . Évalué à 4.

              Mon install d'Ubuntu est l'install par défaut. Si tu relis ce que j'ai écrit, je n'ai jamais installé le laptop mode, et le comportement décrit dans l'article a lieu *par défaut* sur mon ordinateur. Et montre un peu de respect à l'égard de ton roi, on n'est pas en Espagne ici.
              • [^] # Re: unixfix travaillerait pour Paris Match ?

                Posté par . Évalué à 2.

                on t'a deja repondu et a cause de BUG ou mauvaise configuration du bios et/ou de firmware de certains DD (de marque Hitachi principalement) la gestion d'energie de l'ensemble des portables doit etre foutu en l'air?
                • [^] # Re: unixfix travaillerait pour Paris Match ?

                  Posté par (page perso) . Évalué à 3.

                  Qu'est-ce qui interdit de faire un patch qui ne cible que les modèles concernés ?
                  • [^] # Re: unixfix travaillerait pour Paris Match ?

                    Posté par . Évalué à 1.

                    et comment tu les connais les modeles concernes? Les distribs linux c'est pas Miscrosoft et ils ne recoivent pas tous les matos pour tester que l'OS fonctionnera. Deja que c'est rare qu'ils aient la doc...
                    • [^] # Re: unixfix travaillerait pour Paris Match ?

                      Posté par (page perso) . Évalué à 3.

                      A ton avis, comment ça se fait que pour les centaines d'imprimantes qui existent, la quasi intégralité soit utilisable sous linux, et le plus souvent avec des pilotes libres ?

                      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 . Évalué à 1.

                        Par ce que les gens disent "mon imprimante marche pas" quand ils ont besoin d'imprimer, mais qui si tu leur demande si leur imprante fonctionne ils ne te répondront pas. Pareil pour le DD.
                        • [^] # Re: unixfix travaillerait pour Paris Match ?

                          Posté par (page perso) . Évalué à 0.

                          Oui. Et alors ?
                          • [^] # Re: unixfix travaillerait pour Paris Match ?

                            Posté par . Évalué à 2.

                            juste pour info:

                            - 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 (page perso) . Évalué à 3.

                              juste pour info :

                              - 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 . Évalué à -4.

                                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.

                                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 (page perso) . Évalué à 3.

                                  Si tu prenais la peine de lire le message auquel tu réponds, tu serais crédible dans tes accusations. Mon modèle de DD a déjà été signalé comme posant problème, je n'ai aucun besoin d'en rajouter une couche.

                                  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 . Évalué à -5.

                                    MacOS X est considere comme un OS pour madame michu (a juste titre d'ailleurs) et contrairement a ce que tu dis le probleme n'est pas de Ubuntu, Mandriva, RedHat etc (vu que toutes on le meme truc) Le probleme vient du Bios ! Enfin maintenant on va arreter la car franchement cela devient ridicule. Change de distribs si tu veux pas utiliser ubuntu sinon passe sous windows et sinon arrete d'utiliser un ordinateur comme ca tu n'auras plus de DD qui crameront.
                              • [^] # Re: unixfix travaillerait pour Paris Match ?

                                Posté par . Évalué à -1.

                                Tiens a propos un lien fournit dans le lien launchpad que tu mets et que tu devrais lire:

                                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 (page perso) . Évalué à 2.


                        A ton avis, comment ça se fait que pour les centaines d'imprimantes qui existent, la quasi intégralité soit utilisable sous linux, et le plus souvent avec des pilotes libres ?


                        Je dois vivre dans une réalité alternative à la tienne.
          • [^] # Re: unixfix travaillerait pour Paris Match ?

            Posté par . Évalué à 10.

            passé le coup de la colère, que je comprends parfaitement, nous sommes d'accord que :
            - 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 (page perso) . Évalué à 7.

              Très bien, je comprends mieux ce qui nous oppose.

              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 (page perso) . Évalué à -2.

                Dans ce cas : s/Ubuntu/Les distributions Linux/
                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 (page perso) . Évalué à 3.

                  Je n'ai pas cramé de disque dur, et je fais des sauvegardes. Avec celui qui m'appelle le roi des geeks, ça commence à faire du monde qui connaît ma vie mieux que moi.

                  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 (page perso) . Évalué à 1.

                    Je ne prétend pas connaître ta vie, j'essaie de comprendre pourquoi tu es aussi remonté pour ce problème.
                    • [^] # Re: unixfix travaillerait pour Paris Match ?

                      Posté par (page perso) . Évalué à 5.

                      Mais parce que c'est la honte ! On donne du grain à moudre à des distributeurs de café. Ca commence par "Ubuntu crame des DD" sur un blog, ça continue par "Linux détruit vos données" et ça se termine par "le logiciel libre est un cancer pour votre hardware, je vous l'avais bien dit".

                      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 (page perso) . Évalué à 1.

                        Parce que desactiver l'APM des disque dur entraine une surconsommation electrique.
                        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 (page perso) . Évalué à 7.

            Bien sûr que ça dépend un peu du bios et du matériel.
            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 . Évalué à 3.

        Je suis un "gugusse" qui vient de constater 86000 cycles de rangement des têtes sur son portable
        Excuse mon ignorance, mais comment est-ce que tu mesures ça ?
        • [^] # Re: unixfix travaillerait pour Paris Match ?

          Posté par (page perso) . Évalué à 1.

          Comme lu par ailleurs :

          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 (page perso) . Évalué à 2.

            Sur un desktop Mandriva et une machine qui a environ 3 ans:
            193 Load_Cycle_Count 0x0012 099 099 050 Old_age Always - 1436

            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 . Évalué à 3.

            sudo smartctl -d ata -a /dev/hda | grep Load_Cycle_Count
            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 (page perso) . Évalué à 2.

              Ta valeur n'est pas crédible, ce qui ne veut pas dire que la mienne ne l'est pas. La mienne l'est au regard de la fréquence des cricrics que j'entendais (de l'ordre de 5 à 10 fois par minute).
              • [^] # Re: unixfix travaillerait pour Paris Match ?

                Posté par (page perso) . Évalué à 2.

                Moi j'ai des 'cricrics' comme tu dis sur le portable du boulot, avec la loupiote du disque dur qui 'allumait toute les 2 secondes. En fait, c'est hal qui fait un polling toutes les 2 secondes. Le processus fautif s'appelle hald-addon-storage je crois. Il m'a suffit de le tuer pour ne plus avoir ce bruit idiot. Par contre, je ne sais pas comment rendre cela permanent...
                • [^] # Re: unixfix travaillerait pour Paris Match ?

                  Posté par (page perso) . Évalué à 4.

                  Ce n'est pas le même problème, quand il y a un parcage de tête, la loupiote ne s'allume pas. Mais si tu veux fonder un club des anti-bruit à la con de disque dur, je veux bien être trésorier. Vivement la démocratisation des disques durs Flash.
                  • [^] # Re: unixfix travaillerait pour Paris Match ?

                    Posté par (page perso) . Évalué à 3.

                    Je confirme que le problème arrive sur d'autre distribs (ou alors c'est peut être mon BIOS):
                    193 Load_Cycle_Count 0x0032 004 004 000 Old_age Always - 193085

                    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 (page perso) . Évalué à 1.

                      Un truc étrange, moi j'ai :

                      193 Load_Cycle_Count 0x0032 253 253 000 Old_age Always - 0


                      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..

                      SMART support is: Available - device has SMART capability.
                      SMART support is: Enabled

                      === START OF READ SMART DATA SECTION ===
                      SMART overall-health self-assessment test result: PASSED


                      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 (page perso) . Évalué à 3.

                  C'est pas hald qui cause cette activité toutes les 2 ou 3 secondes, je l'ai arrêté et ça continue.
                  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 . Évalué à 2.

                    Par contre (j'ai lu que) c'est la journalisation ext3 qui fait ça.

                    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 . Évalué à 9.

    Comme le dit Matthew Garrett[http://mjg59.livejournal.com/77672.html] le laptop-mode n'est pas activé par défaut dans Ubuntu et le problème semble plutôt venir du bios du fabriquant que d'Ubuntu. D'ailleurs la durée de vie de "11 à 12 mois" est une valeur théorique et qui a l'air assez extrême, rien ne dit que dans la pratique le DD ne dure pas plus longtemps.
    • [^] # Re: Oui mais...

      Posté par . Évalué à 3.

      C'est vrai car pour un desktop laptop_mode est en soit inutile. Cependant un utilisateur de laptop même s'il n'est pas un geek va clicker laptop_mode s'il a un laptop.

      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 . Évalué à 10.

        Cependant un utilisateur de laptop même s'il n'est pas un geek va clicker laptop_mode s'il a un laptop.

        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 . Évalué à 5.

        tu veux dire mettre un message comme cela:

        # 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 . Évalué à 2.

          # Switch to laptop-mode on battery power - off by default as it causes odd
          # 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 . Évalué à 10.

    tout ça est un peu confus pour moi.

    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.
    • [^] # Re: confus pour moi

      Posté par . Évalué à 7.

      Pareil. Sinon j'ai trouvé ça lors de mes recherches pour éclaircir la situation :

      -> http://gentoo-wiki.com/HOWTO_HDD_spindown_small_server#Kerne(...)

      « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: confus pour moi

      Posté par . Évalué à 10.

      Je vais essayer d'expliquer un peu plus en détail ce que j'ai remarqué là dessus. tout d'abords le décors : Je n'utilise pas *ubuntu, mais des mandrakes/mandriva, en particulier sur des laptops depuis ~2000. J'ai remarqué ce problème de load/unload fréquents dès 2003 suite au bruit agaçant que fait le disque lorsqu'il décharge les têtes.

      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 . Évalué à 9.

        Merci a ceux qui m'ont lu jusqu'au bout !!

        Merci à toi pour cette excellent tuto. en rentrant ce soir, je vérifie mes paramètres :-)
      • [^] # Re: confus pour moi

        Posté par . Évalué à 4.

        Très intéressant post, j'ai beaucoup appris.
        C'est donc moi qui te remercie.
        Bye
      • [^] # Re: confus pour moi

        Posté par . Évalué à 10.

        Très bonne remarque.

        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 . Évalué à 6.

        tres bon post et d'apres ce que tu mets les deux options importantes sont:

        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 . Évalué à 3.

          Oui. Encore faut-il que le laptop_mode soit activé sur secteur, sinon ces valeurs ne sont pas appliquées. Or ceci n'est pas la valeur par défaut (sur mdv)

          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 (page perso) . Évalué à 0.

        Ok pour tout ça, sauf :

        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 . Évalué à 5.

          "Ton expérience [...] n'a malheureusement aucune valeur statistique."

          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 (page perso) . Évalué à 2.

            c'est vrai qu'il m'arrive de mettre des gros coups de genou sous le bureau en croisant les jambes et de voir le portable sauter d'1cm :) Là l'argument s'inverse, j'ai probablement évité plusieurs fois de le bousiller grâce à l'unload.
      • [^] # Re: confus pour moi

        Posté par . Évalué à 1.

        Comment fait-on pour monter tous ces répertoires temporaires en RAM ?

        Merci
  • # Beranger.org est il encore crédible ?

    Posté par (page perso) . Évalué à 10.

    Ça fait déjà deux boulettes que je le vois le sieur Radu-Cristian Fotescu (propriétaire de beranger.org) relayer en une semaine. Ici il dit que Ubuntukipu va détruire votre disque dur et que c'est une raison pour ne plus utiliser Ubuntukipu.
    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 . Évalué à 2.

      Dés fois Beranger.org exagère et a une dent contre Ubuntu. mais dans ce cas précis visiblement le problème est réel (est d'ailleurs un bug officiel).

      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 . Évalué à 2.

      Bon, écoute, je ne fais que de passer à la suite logique de ce qu'on disait sur d'autres sites.

      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 (page perso) . Évalué à 10.

        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.

        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:
        Stop using that møtherføøer Ubuntu! Now you have a strong reason for that! Quit *buntu and never look back.

        ...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 (page perso) . Évalué à 4.

        beranger:
        Bon, écoute, je ne fais que de passer à la suite logique de ce qu'on disait sur d'autres sites.

        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:
        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 ?

        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 :
        But, as I said, that's not the default behaviour of Ubuntu.

        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:
        Je rends un service public, les potes ! :-)

        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 . Évalué à 10.

      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.

      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 . Évalué à 6.


        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é.


        c'est justement ce qu'ils font puisque le laptop-mode est désactivé par défaut.
  • # S*l*perie.......

    Posté par . Évalué à 3.

    Ca me stressait, je me doutais bien que c'était pas normal.
    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 . Évalué à 4.

      Je pense que cela vient plus de la machine que du disque dur, j'avais moi aussi le doute et voici le test que j'ai fait (posté sur le forum matériel Ubuntu au même topic) :

      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.
  • # Autodestruction

    Posté par . Évalué à 4.

    Je suis l'heureux possesseur d'un ultra portable de 2001, un Gateway Solo 3350, mais le même, peut-être dans une qualité un peu meilleure (au moins pour la coque), a aussi été vendu sous la marque Dell (Latitude L400 je crois).
    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 ?

    Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

    • [^] # Re: Autodestruction

      Posté par . Évalué à 1.

      tu compile le noyau une fois par minute ?

      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 (page perso) . Évalué à -1.

        Bonsoir

        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
      • [^] # Mon script

        Posté par . Évalué à 4.

        tu compile le noyau une fois par minute ?

        Je veux pouvoir encore faire quelque chose avec ma machine ! :-)

        j'imagine que c'est un dd bien placé dans le cron

        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.

        combiné avec sync ?

        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.

        tu aurais pus poster le script car il ne doit pas etre tres grand :)

        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

        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.