Journal Obsolescence programmée ou pas ?

Posté par benoar le 23 octobre 2013 à 01:43. Licence CC By‑SA.

Étiquettes : aucune

oct.

2013

Continuons dans le débat lancé par Florent dans son journal (coucou au passage _o/ t'aurais pu me demander, moi j'étais au courant de ce bug…).

J'ai un joli NAS acheté d'occasion, et je veux voir l'état des disques, car je trouve qu'il fait parfois des bruits un peu étranges. Extrait du "smartctl -a" sur un disque :

…
  9 Power_On_Hours          0x0012   058   058   000    Old_age   Always       -       18559
…
193 Load_Cycle_Count        0x0012   008   008   000    Old_age   Always       -       926784
…

Wouhou ! Plus de 900000 cycles de chargement/déchargement ? C'est énorme !
Pour ceux qui ne connaissent pas, cette caractéristique est très liée à la fiabilité d'un disque, et la valeur au dessus de laquelle est n'est plus garantie se trouve pour un disque de 2,5" généralement entre 300000 (pour les disques « grand pulbic ») et 600000 cycles (pour les disques plus « pro »). Voir ici par exemple. Regardons la datasheet du disque en question : j'ai de la « chance », c'est 600000, mais il est donc bien au dessus…

Faisons un petit calcul : 18559h de fonctionnement, ça fait un peu plus de deux ans. Le rythme de parquage des têtes était (avec la configuration d'origine, je précise) de 926784 cycles / 18559 h ≈ 50 cycle/h, soit un peu moins d'un par minute. C'est beaucoup, surtout pour un appareil qui ne bouge théoriquement pas, par rapport à un portable (le parquage est souvent effectué pour « protéger » les têtes lors des chutes ou des mouvements brusques). Et donc, à ce rythme, au bout de combien de temps dépasse-t-on la limite de vie du disque ? 600000 / 50 = 12000 heures = 500 jours = un peu plus d'un an et quatre mois… bon, la garantie est normalement de deux ans, on peut pas dire qu'ils aient fait super gaffe, là.

Mais donc, est-ce normal que ce genre de matos nique les disques si vite ? Est-ce délibéré ? Est-ce juste de l'incompétence ? Est-ce la durée de vie « normale » ? Rappelons que dans ce cas, l'OS d'origine est Linux ; dans le cas des laptops classiques, on avait souvent accusé Linux de provoquer trop de cycles de chargement contrairement à Windows, ce qui faisait que ça n'était pas la « faute » du constructeur si les chargements étaient si nombreux (mais leur conf était bien d'éteindre le disque très rapidement, et donc de provoquer un parquage dès que possible). Perso, je pense que c'est juste que les mecs n'ont même pas fait gaffe. Mais ça fout quand même les boules de merder à ce point.

Bon, un disque vient de terminer un test SMART long : pas d'erreurs. Croisons les doigts… (et essayons le RAID intégré à LVM dans wheezy, ça a l'air marrant).

Pour info, sur le même modèle de NAS, acheté neuf, configuré par mes soins, je suis à 10913h pour 269146 cycles, et il a quand même le temps de se mettre en économie d'énergie pas mal de fois (ouai, bon, au final, ça fera un peu moins de trois ans seulement pour arriver à la limite… mais je ne l'ai pas configuré tout de suite).

# Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.

Posté par SaintGermain le 23 octobre 2013 à 02:32. Évalué à 7.

Bon ok j'exagère un peu avec mon titre.

À mon avis c'est un double problème : tu as un process qui réveille le disque en permanence + un mauvais réglage qui est trop agressif sur la mise en veille du disque.

Certains Western Digital sont réputés pour l'agressivité de leur mise en veille :
https://wiki.archlinux.org/index.php/Advanced_Format#Special_Consideration_for_WD_Green_HDDs

Mais le coeur du problème, c'est trouver ton process qui réveille ton disque. C'est en général pas trop dur à trouver (il faut juste logger tous les accès disques et tu trouveras rapidement le coupable).
- [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
  
  Posté par Le Gab le 23 octobre 2013 à 02:56. Évalué à 1.
  
  Concevoir un NAS, c'est inévitablement prendre en compte ce genre de facteurs en compte, non?
  Après, l'ami plus haut n'a pas spécifié de quelle marque de NAS il s'agissait et dans quelle gamme il se situait même si normalement ça de ne devrait en rien excuser ce comportement, ce n'est pas un luxe d'assurance qualité, si?
- [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
  
  Posté par Jean Canazzi le 23 octobre 2013 à 04:51. Évalué à 2.
  
  Merci pour le lien, je possède justement un NAS avec deux disques Western Digital "Green", et ils font des bruits bizarres tout le temps ! J'ai appris plus tard qu'il ne fallait surtout pas mettre des "green" dans un NAS, car ils ont pour but l'économie d'énergie et donc (donc ?) le parcage des têtes aussitôt que possible (c'est à dire : après 8 secondes d'après ton lien).
  Dans un NAS, les forumeurs recommandent de mettre des Western Digital "red", conçus pour ce genre d'usage. Si on utilise son NAS comme seedbox ou autre usage qui sollicite les disques constamment, c'est mieux.
  - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
    
    Posté par lepoulpe le 23 octobre 2013 à 09:38. Évalué à 6.
    
    À noter qu'il existe un utilitaire pour régler la durée avant le parcage des tête : http://idle3-tools.sourceforge.net/. Il y a aussi une version officielle pour Windows chez WD : http://support.wdc.com/product/download.asp?groupid=609&sid=113&lang=fr
    
    Ça permet de passer de la valeur par défaut (8s) à quelque chose de plus correct (j'ai du mettre quelque chose de l'ordre de 5mn sur les 4 WD Green de mon NAS).
  - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
    
    Posté par SF le 23 octobre 2013 à 17:09. Évalué à 2.
    
    Personnellement je fuis les WD Green, les deux miens n'ont pas tenu un an et leurs remplaçants via la garantie pas plus longtemps.
    Ca se termine toujours dans d'atroces craquements. Le point positif est que j'ai toujours réussi à récupérer les données.
    - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
      
      Posté par karteum59 le 23 octobre 2013 à 21:25. Évalué à 3.
      
      je fuis les WD Green, les deux miens n'ont pas tenu un an
      
      Et ils osent appeler ça "green"…
- [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
  
  Posté par Xaapyks le 23 octobre 2013 à 09:26. Évalué à 0.
  
  +1
  Des disques 2.5 dans un NAs c'est suicidaire.
  
  Pour les load élevés, c'est pas trouver ce qui réveille le disque qui est essentiel, mais plutôt de désactiver le sleep. De mémoire c'est hdparm -B 254 ou 255 il me semble (à vérifier, un peu la flemme là)
  - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
    
    Posté par olaf le 23 octobre 2013 à 09:42. Évalué à 0.
    
    Vraiment ?
    http://www.ldlc.com/fiche/PB00134441.html
  - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
    
    Posté par gouttegd le 23 octobre 2013 à 09:45. Évalué à 2.
    
    De mémoire c'est hdparm -B 254 ou 255
    
    C’est 254. On peut aussi jouer avec le délai d’inactivité au bout duquel les têtes sont parquées, avec -S. Chez moi, ce délai est réglé à 5 minutes (-S 60) sur batterie, et à deux heures (-S 244) sur secteur,
    - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
      
      Posté par benoar le 25 octobre 2013 à 00:11. Évalué à 2.
      Ici, sur ce NAS, j'ai dans /etc/default/hdparm :
      
      hdparm_opts="-B254 -S36"
  - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
    
    Posté par ChickenKiller le 23 octobre 2013 à 14:39. Évalué à 5.
    
    Des disques 2.5 dans un NAs c'est suicidaire.
    
    C'est sûrement pour ça que TOUS les constructeurs de serveur se mettent au 2.5 et qu'ils sont largement aussi fiable que les 3.5…
    - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
      
      Posté par Xaapyks le 23 octobre 2013 à 20:38. Évalué à 2.
      
      Le marché fait toujours les meilleurs choix, c'est bien connu…
      Ca c'est surement amélioré mais argumenter en disant que c'est forcément aussi bien voire mieux car tous les fabricants s'y sont mis n'a pas de sens…
      - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
        
        Posté par ChickenKiller le 23 octobre 2013 à 22:25. Évalué à 2. Dernière modification le 23 octobre 2013 à 22:27.
        
        En tous cas, d'expérience personnel (oui je sais ça n'a rien de représentatif), je ne vois pas en quoi ça peut être un mauvais choix.
        
        Une raison particulière (étude personnelle ou autre) pour dire ça? En quoi le format joue? Parce que du coup ça m'a pas plus de sens de décréter que les disques 2.5 ne sont pas fiables.
        Et si c'est juste le fait de dire que les disques dur de pc portables claquent plus souvent que les autres … pour un disque qui se fait trimbaler c'est un peu normal et un 3.5 ne ferait pas mieux.
        
        [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
        
        Posté par Xaapyks le 24 octobre 2013 à 09:59. Évalué à 2.
        
        J'ai vu plus de 2.5" morts que de 3.5" dans ma vie, mais tu as raison les contraintes ne sont pas les même. Je pars aussi du principe que la miniaturisation doit amener des contraintes de plus. Alors qu'il y a 2 ou 3 années, un disque de base en 3.5" tournait en général à 7200 et un 2.5 à 5400 RPM.
        
        [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
        
        Posté par ChickenKiller le 24 octobre 2013 à 12:58. Évalué à 1.
        
        D'accord, mais le principal problème de la miniaturisation se traduit le plus souvent par la densité de stockage sur la surface du de par les contrainte technique reste fixe. Du coup on se retrouve en général avec des disques qui ont une capacité inférieure.
        Concernant la vitesse de rotation, le problème n'est pas un problème de miniaturisation, mais le fait que plus la vitesse est élevée plus il est difficile de supporter les chocs. La preuve en est que malgré les années, les disques à 7200 RPM sur portable sont encore rares et que les fabricant de portables sont très friand de SSD (plus que les fixe) car ils tiennent beaucoup mieux les chocs tout en ayant de très bonne perf.
        De plus, il y a déjà 2 ou 3 ans de cela on trouvait déjà des disques SAS 2.5 à 15K RPM, mais ils sont prévu pour rester bien au chaud au fond d'un datacenter et ils ne subiront donc que peu de chocs dans leur vie :-)
      - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
        
        Posté par Big Pete le 24 octobre 2013 à 00:26. Évalué à 10.
        
        Un peu de mise en perspective ne pouvant pas faire de mal, si je puis me permettre :
        
        Stockage de données sur disque, États-Unis, 1970, 16 Mo.
        
        Stockage de données sur disque, Mexique, 1479, moins d'1 Ko, a vue de nez.
        
        (Note que certains prétendent que la lecture et l’écriture des données nécessitait le sacrifice d'un certains nombre de vierges, et que ce n'était pas pratique, mais au moins, les ayants-droits pouvaient dormir tranquille).
        
        Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
    - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
      
      Posté par benoar le 25 octobre 2013 à 00:15. Évalué à 3.
      
      Les constructeurs se mettent au 2,5" plus pour la conso d'énergie et la densité (oui, la densité au sens volumique du terme : on fait tenir plus avec des 2,5" que des 3,5" dans un serveur, i.e. il existe des 2To en 2,5" pour 4To en 3,5", alors que la différence de taille (physique) est énorme). Car question fiabilité, les 2,5" qu'ils utilisent ne sont pas ceux du commerce, à part pour les grosses fermes de données où on s'en fout que ça soit fiable à 3,5 ou 2,5" ; c'est des SAS 10k ou 15k, nettement plus endurant. Et aussi, ça permet de rentrer des SSD, qui sont encore plus prisés quand on veut vraiment des perfs.
- [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
  
  Posté par Ely le 23 octobre 2013 à 10:17. Évalué à 2.
  
  Ouaip, j'avais commandé des WD Green pour un NAS justement, et ils ont grillé au bout de 6 mois. Heureusement, j'ai pu faire jouer la garantie.
  
  Il semblerait que le problème aille au-delà d'un process agressif cependant, car j'ai les mêmes disques sur ma workstation sous windows et je n'ai jamais pu reproduire le problème..
  - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
    
    Posté par gUI (Mastodon) le 25 octobre 2013 à 12:00. Évalué à 2.
    
    Oui, d'ailleurs WD a sorti al série Red, officiellement destinée aux NAS.
    
    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
- [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
  
  Posté par benoar le 25 octobre 2013 à 00:10. Évalué à 2.
  
  Mais le coeur du problème, c'est trouver ton process qui réveille ton disque. C'est en général pas trop dur à trouver (il faut juste logger tous les accès disques et tu trouveras rapidement le coupable).
  
  Franchement, non, ça n'est pas ça le problème : c'est normal que l'OS veuille écrire des trucs de temps en temps. Par exemple, il sert également de client bittorrent (chose proposée également sur le firmware d'origine, donc il n'y a pas de raison que ça soit « hors spec »). Le truc, c'est que le disque n'a pas à parquer ses têtes toutes les 30s quand c'est du matos fait pour ne pas bouger.
  
  Quant à la « facilité » de trouver les accès disques, j'avais déjà essayé à une époque, ça n'est pas si simple que ça, ou alors je veux bien une doc :-)
  - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
    
    Posté par SaintGermain le 25 octobre 2013 à 11:09. Évalué à 3.
    
    Franchement, non, ça n'est pas ça le problème : c'est normal que l'OS veuille écrire des trucs de temps en temps. Par exemple, il sert également de client bittorrent (chose proposée également sur le firmware d'origine, donc il n'y a pas de raison que ça soit « hors spec »). Le truc, c'est que le disque n'a pas à parquer ses têtes toutes les 30s quand c'est du matos fait pour ne pas bouger.
    
    Oui tu as raison, les deux problèmes sont en fait aussi importants l'un que l'autre.
    
    Je suppose que dans l'idéal il faudrait pouvoir régler le délai avant parquage des têtes en fonction de son utilisation du NAS. Si tu fais du bittorrent à longueur de journée, cela n'a même plus de sens de chercher à parquer les têtes (puisqu'il va probablement y avoir une demande d'accès dans les 5 mn).
    
    A l'inverse, si tu as bien réglé ton délai avant parquage à une valeur raisonnable de 5 mn, cela ne servira à rien si tu as un process parasite qui accède au disque toutes les 3 mn.
    
    Quant à la « facilité » de trouver les accès disques, j'avais déjà essayé à une époque, ça n'est pas si simple que ça, ou alors je veux bien une doc :-)
    
    Ce n'est pas si compliqué que cela (enfin c'est relatif je te l'accorde). Si cela t'intéresse tu peux faire une demande sur le forum et j'y répondrai.
    - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
      
      Posté par benoar le 28 octobre 2013 à 11:26. Évalué à 2.
      
      Si tu fais du bittorrent à longueur de journée, cela n'a même plus de sens de chercher à parquer les têtes (puisqu'il va probablement y avoir une demande d'accès dans les 5 mn).
      
      A l'inverse, si tu as bien réglé ton délai avant parquage à une valeur raisonnable de 5 mn, cela ne servira à rien si tu as un process parasite qui accède au disque toutes les 3 mn.
      
      Je ne comprends pas : dans les deux cas, tu as une période d'utilisation inférieure à la période de parquage, et donc les têtes ne se parquent jamais. On aurait un accès toute les demi-heure, avec un parquage de 5 min, ça ferait un nombre de chargements raisonnables. Bref, pas besoin de faire « en fonction » de l'utilisation, une valeur genre 5 minutes irait très bien pour une machine fixe. Le mettre à 30s sur un laptop, pourquoi pas, même si je ne suis pas convaincu de l'effectivité de la résistance aux chocs…
      
      Ce n'est pas si compliqué que cela (enfin c'est relatif je te l'accorde). Si cela t'intéresse tu peux faire une demande sur le forum et j'y répondrai.
      
      Merci, c'est sympa, mais je n'ai pas trop le temps de faire ça pour l'instant. Une autre fois, peut-être.
      - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
        
        Posté par SaintGermain le 28 octobre 2013 à 15:24. Évalué à 3.
        
        Je ne comprends pas : dans les deux cas, tu as une période d'utilisation inférieure à la période de parquage, et donc les têtes ne se parquent jamais. On aurait un accès toute les demi-heure, avec un parquage de 5 min, ça ferait un nombre de chargements raisonnables. Bref, pas besoin de faire « en fonction » de l'utilisation, une valeur genre 5 minutes irait très bien pour une machine fixe. Le mettre à 30s sur un laptop, pourquoi pas, même si je ne suis pas convaincu de l'effectivité de la résistance aux chocs…
        
        Les deux exemples montrent que si tu "corriges" un des deux aspects (délai avant parquage ou process parasite) en négligeant l'autre aspect, tu obtiens un comportement insatisfaisant dans certains cas d'utilisation.
        
        Donc au final, pour avoir un comportement satisfaisant il faut vérifier qu'il n'y a pas de process parasite et régler son délai avant parquage à une valeur adaptée à son utilisation.
        
        Pour une utilisation bittorrent: 5 mn c'est pas mal.
        Pour un portable: je crois qu'effectivement les 8 s des WD c'était pour protéger le disque en cas de choc (dans ce cas 5 mn c'est vraiment trop).
        Pour un NAS en environnement pro qui doit répondre assez vite: je mettrais 2-3h (histoire qu'il s'arrête la nuit)
        
        Comme process parasite rigolo, j'ai eu mon lot de surprises : firefox qui synchronisait toutes les 30s, des process qui loggaient pour pas grand chose (--mark-- dans syslog), des CRON se déclenchant toutes les heures sans réelle utilité, etc.
        Bref arriver à avoir un système GNU/linux qui se mette en idle, c'est pas vraiment facile !
        
        [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
        
        Posté par benoar le 28 octobre 2013 à 19:21. Évalué à 2.
        
        Donc au final, pour avoir un comportement satisfaisant il faut vérifier qu'il n'y a pas de process parasite et régler son délai avant parquage à une valeur adaptée à son utilisation.
        
        Ah ok ; c'est juste que depuis le début je ne me concentrais que sur mon utilisation : là tu dois parler également de ceux qui utilisent un portable et qui veulent que le disque se mette en veille au bout d'un moment pas trop long sans process pour le réveiller trop souvent.
        
        Comme process parasite rigolo, j'ai eu mon lot de surprises : firefox qui synchronisait toutes les 30s,
        
        Ah, firefox qui fsync toute ta navigation… j'aimerais bien montrer la débilité de la chose avec un « vieux » smartphone qui freeze 10s (oui oui, 10s) à chaque visite d'un lien car il le sauvegarde dans l'historique, et je soupçonne que la cause est le contrôleur de la flash qui galère à mort à faire sa tambouille pour trouver de la place en flash… (contrôleur eMMC sans TRIM, je suppose). (ya un thread sur un autre journal là-dessus en ce moment)
        
        des process qui loggaient pour pas grand chose (--mark-- dans syslog),
        
        Oui, mais ça peut parfois être utile pour savoir qu'il ne s'est pas arrêté, peut-être.
        
        des CRON se déclenchant toutes les heures sans réelle utilité, etc.
        
        Oui. Si tu (on ?) pouvais remonter remonter ça upstream avec des bugreports sympas, afin de trouver une solution à ça, ça serait génial… :-)
        
        [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
        
        Posté par SaintGermain le 29 octobre 2013 à 10:30. Évalué à 1.
        
        des CRON se déclenchant toutes les heures sans réelle utilité, etc.
        
        Oui. Si tu (on ?) pouvais remonter remonter ça upstream avec des bugreports sympas, afin de trouver une solution à ça, ça serait génial… :-)
        
        J'essaye toujours de remonter les problèmes quand je peux :
        http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710803
        (là pour le coup c'est pas upstream le problème mais un patch Debian)
        
        [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
        
        Posté par benoar le 29 octobre 2013 à 18:10. Évalué à 2.
        
        J'essaye toujours de remonter les problèmes quand je peux :
        http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710803
        
        Super, merci pour la référence. Je m'y mettrais un jour si je trouve un peu de temps.
- [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
  
  Posté par groumly le 25 octobre 2013 à 06:10. Évalué à 0.
  
  Et tu fais quoi une fois que tu l'as trouve, le process?
  Tu lui d'arreter d'acceder disque?
  Et si c'est un client bittorrent, un serveur http ou un outil de backup automatique, tu fais quoi?
  
  Linuxfr, le portail francais du logiciel libre et du neo nazisme.
  - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
    
    Posté par ckyl le 25 octobre 2013 à 11:06. Évalué à 6.
    Deux cas:
    - Tu as une machine qui est censée idler, tu trouves le process et tu fais en sorte qu'il arrête de reveiller le disque en permanence.
    - Tu as une machine qui fait des IO en permanence (seedbox & co) et dans ce cas la tu configures le parquage des têtes en conséquence. Ca ne sert à rien d'aller les parquer après 5s d'idle si ta machine fait des IO toutes les 10s.
    Bref tu fais en sorte que la conf du parquage corresponde à l'utilisation de la machine.
    - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
      
      Posté par SaintGermain le 25 octobre 2013 à 11:17. Évalué à 2.
      
      Tu m'enlèves les mots de la bouche. ;-)
      
      A noter que régler le délai avant parquage des têtes est un défi en soi.
      
      Avec mon WD je n'ai toujours pas réussi à avoir ce que je voulais.
      Et pourtant j'ai essayé à grand coup de hdparm et de idle3 mais il ne veut rien savoir. Au final j'ai baissé les bras, et me suis résigné à le voir tourner en permanence sans parquage.
      
      Pour ceux que cela intéresse, je me suis aussi renseigné pour un boîtier externe USB3 dont le chipset gère lui-même la mise en veille (ASMEdia ASM1051 par exemple). Et ben là aussi c'est le far west et je n'ai pas réussi à trouver.
      - [^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
        
        Posté par benoar le 28 octobre 2013 à 11:40. Évalué à 3.
        
        Pour ceux que cela intéresse, je me suis aussi renseigné pour un boîtier externe USB3 dont le chipset gère lui-même la mise en veille (ASMEdia ASM1051 par exemple). Et ben là aussi c'est le far west et je n'ai pas réussi à trouver.
        
        À noter pour les disques USB : certains permettent de passer des commandes directement au disque avec sdparm (plutôt que hdparm). Et depuis l'USB3, il y a normalement l'“USB Attached SCSI” qui permet également cela, dans le standard et donc normalement utilisable partout. Par contre, je ne sais pas ce qu'il en est du support soft.
# 4383.56 ans

Posté par gnujsa le 23 octobre 2013 à 08:56. Évalué à 10.
Si je compare 2 disques un peu similaires, un qui est sur mon ordi fixe qui tourne sous Debian et le deuxième, un disque externe utilisé sur le portable de ma copine sous Unbuntu. Je trouve des valeurs extrêmements différentes:
```
Le mien :
Power_On_Hours        39143
Load_Cycle_Count        609

Le sien:
Power_On_Hours        14583
Load_Cycle_Count     149621
```
Sur le sien, les têtes sont parkées en moyenne, une fois toutes les 6 minutes, ce qui lui donne une durée de vie théorique totale (en prennant le chiffre de 600000 parkages) de 2 ans et demis, tandis que sur le mien, elles sont parkées une fois toutes les 64 heures, ce qui donne une durée de vie théorique totale de 4383.56 ans. D'ici là, la prochaine Debian stable sera sortie, c'est cool !
- [^] # Re: 4383.56 ans
  
  Posté par Ontologia (site web personnel) le 23 octobre 2013 à 15:38. Évalué à 6.
  
  Pardon de poser la question de l'ignare total que je suis sur ces questions, mais faire un parquage des têtes trop réguliers provoque un vieillissement prématuré du disque dur ?
  
  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
  - [^] # Re: 4383.56 ans
    
    Posté par Toto le 23 octobre 2013 à 17:22. Évalué à 5.
    
    Je suis pas un spécialiste du disque dur, loin de la, mais je suppose que le parquage des têtes mets en jeux différents éléments mécaniques (type verrou pour éviter que la tête ne bouge par exemple). On peut d'ailleurs parfois entente un petit cliquetis lors du parquage.
    Or comme tout élément mécanique, plus on les utilisent, plus ils vieillissent. Donc parquer régulièrement les têtes va user ce mécanisme, et donc du coup limiter la durée de vie du DD
# Disque WD économie d'énergie

Posté par Anonyme le 23 octobre 2013 à 09:16. Évalué à 2.

Cette histoire me rappelle le claquage de mon disque dur de portable ayant lâché au bout d'une année. En heures de fonctionnement, on était en dessous de l'année complète avec 12h/jour, mais bon… le fait est que ce disque n'arrêtait pas de parquer les têtes et de les ressortir dès qu'activité il y avait.

Le petit cliquetis attestait de cette activité…

Un beau jour, alors que je commençais les cours et que oh, on faisait du LVM, eh bah… auf wiedersehen.

Tout ça pour dire qu'il faut aussi faire attention aux disque "économiques". Au final, ça se paie en nouveau disque dur.
# Moi aussi je peux jouer ?

Posté par Thibault (site web personnel) le 23 octobre 2013 à 10:17. Évalué à 4.
On gagne quoi ? :)
```
   9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       18388
 225 Load_Cycle_Count        0x0032   001   001   000    Old_age   Always       -       15060379
```
Ce qui m'en fait à peu près un toutes les 5 secondes (et on l'entend bien).
Au début j'avais essayé de jouer avec les paramètres du hdparm, mais sans effet.
Depuis j'ai laissé couler, et j'ai jamais eu de problèmes (pour l'instant…)

Pour ceux que ça intéresse, c'est un SAMSUNG HM500JI.
- [^] # Re: Moi aussi je peux jouer ?
  
  Posté par benoar le 25 octobre 2013 à 00:16. Évalué à 2.
  
  Je pense que c'est plutôt une valeur erronée, ça me paraît complètement impossible. Il y a beaucoup de valeurs SMART qui ne veulent rien dur car niveau standardisation, c'est un peu la misère.
  - [^] # Re: Moi aussi je peux jouer ?
    
    Posté par Thibault (site web personnel) le 27 octobre 2013 à 19:27. Évalué à 1.
    
    Ça je veux bien le croire. Surtout quand la valeur est très supérieure à la moyenne.
    Mais si je colle l'oreille, j'entends bien un petit "tac" toutes les cinq secondes, et la valeur SMART est incrémentée de un à chaque fois…
    
    Soit le disque est vraiment hyper costaud, soit je ne sais pas. En tout cas je m'attends à ce qu'il lâche d'un moment à l'autre. J'ai l'impression qu'il a perdu un peu de ses performances d'antan.
    - [^] # Re: Moi aussi je peux jouer ?
      
      Posté par benoar le 28 octobre 2013 à 11:28. Évalué à 3.
      
      Mais si je colle l'oreille, j'entends bien un petit "tac" toutes les cinq secondes, et la valeur SMART est incrémentée de un à chaque fois…
      
      Ça me rappelle un disque que j'avais sur un laptop, qui est mort d'un trop grand nombre de (dé)chargements de tête. Ça serait pas un Hitashi ? J'avoue ne pas comprendre comment on peut arriver à mettre une si petite période, mais bon… mystère.
      - [^] # Re: Moi aussi je peux jouer ?
        
        Posté par Thibault (site web personnel) le 30 octobre 2013 à 02:09. Évalué à 2.
        
        Non, c'est un Samsung HM500JI.
        
        D'ailleurs il semble que je ne suis pas le seul à m'apercevoir du Load_Cycle_Count très élevé/fréquent (d'après Google).
        
        Pour la petite histoire, le disque a fait ses premiers Emask 0x409 (media error) et autres Buffer I/O error aujourd'hui.
        Après je ne sais pas si c'est dû au parquage (il n'y a pas de raison que ça le soit), où au fait qu'il ait malencontreusement pris quelques G… :p
# Selon l'utilisation...

Posté par Nanawel (site web personnel, Mastodon) le 23 octobre 2013 à 12:50. Évalué à 1.

Mon NAS Synology tourne depuis plus de 8 mois maintenant avec 3 disques WD Green et 1 WD Red.

Le Red a un LCC de… 2.

Pour les Greens par contre j'en ai deux qui dépassent à peine 2000, alors que l'autre est à plus de 200 000. J'imagine que cela dépend de sa sollicitation selon l'agencement du RAID. Ici mes disque ne se mettent que très rarement en veille puisque j'ai une radio qui diffuse la musique stockée dessus en continu. Je touche du bois mais dans cette situation ce n'est pas le LCC qui me fait peur :) (ou au moins je sais quel disque surveiller plus attentivement !)
- [^] # Re: Selon l'utilisation...
  
  Posté par Big Pete le 23 octobre 2013 à 13:54. Évalué à 1.
  
  A priori synology a intégré l'outil pour désactivé l'idle3 des WD Green a partir de la version 1922 du DSM. Cf http://forum.synology.com/enu/viewtopic.php?f=124&t=41515
  
  Chez moi j'ai du Samsung sur un nas DS411 et pas de souci de coté.
  
  Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
- [^] # Re: Selon l'utilisation...
  
  Posté par benoar le 25 octobre 2013 à 00:19. Évalué à 1.
  
  Le Red a un LCC de… 2.
  
  Au début, j'ai pensé à une valeur erronée, mais en fait c'est peut-être bien vrai. Je viens de voir qu'en fait, le LCC de mon autre NAS n'a pas bougé depuis 48h ; avec les bons réglages, ça marche bien. Mais comme je disais, c'est plutôt les réglages inconscients d'origine qui m'horripilent.
  
  J'imagine que cela dépend de sa sollicitation selon l'agencement du RAID.
  
  Peut-être. Ça voudrait dire que celui à 200 000 est vraiment peu sollicité (paradoxalement), et que ses réglages sont pourris : mieux vaut corriger ça avant qu'il merde vraiment.
# Rien à voir mais tant qu'on est là à parler de disquer dur

Posté par Le Gab le 23 octobre 2013 à 14:27. Évalué à 10.

Il y a un super article sur le bidouillage d'un contrôleur de disque WD Green, le gars a réussi à utiliser le micro-contrôleur - apparemment un cœur ARM - et la mémoire (64MB) pour y faire tourner un noyau Linux et quelques outils en espace utilisateur:

http://spritesmods.com/?art=hddhack

Et il y a d'autres pépites sur ce site.
- [^] # Re: Rien à voir mais tant qu'on est là à parler de disquer dur
  
  Posté par benoar le 25 octobre 2013 à 01:00. Évalué à 2.
  
  Merci pour le lien, très intéressant. J'ai déjà vu des points de connexions sur des SSD qui ressemblent trop à un port série ou à un JTAG… je me suis toujours dit qu'il fallait que j'essaye un jour. Mais bon, pas le temps…
# Quid de la fiabilité des informations SMART ?

Posté par Guillaume T le 23 octobre 2013 à 14:34. Évalué à 3.

Juste une idée en l'air probablement, mais va comprendre : à chaque fois que je regarde les datas smart d'un HDD, la catastrophe doit toujours être imminente. Pourtant, ces disques tournent toujours 3 ans après…
- [^] # Re: Quid de la fiabilité des informations SMART ?
  
  Posté par phoenix (site web personnel) le 23 octobre 2013 à 15:16. Évalué à 4.
  
  Il me semble que ce n'est pas tant la valeur donnée par SMART qui est important mais son évolution.
  
  Exemple un disque avec des "Reallocated Sector" (neuf ou vieux), ne posera aucun soucis tant que la valeur ne bouge pas. (Les secteurs ré-alloués peuvent être d'origine, d'où l'utilité de faire un "badblocks -svw" du disque à l'achat). Si la valeur commence à grimper là il faut s'inquiéter.
  
  Les valeurs en Pre-Fail indiquent que si on dépasse le seuil, il commence à y avoir un risque que le disque va être HS.
  Les valeurs en Old-Age indique juste que le disque commence à être un peu vieux, et non que le disque va mourir (un vieux disque peut durer longtemps). Et il ne parait pas déconnant que les constructeurs calculent la valeur max de Old-Age pour tomber aux environs de la fin de garantie dans le cadre d'une utilisation qu'ils estiment normal pour la gamme du disque dur.
  - [^] # Re: Quid de la fiabilité des informations SMART ?
    
    Posté par jinbeman le 24 octobre 2013 à 12:13. Évalué à -1. Dernière modification le 24 octobre 2013 à 12:15.
    Mouai, ça c'est la théorie (pour le Old-age / Pre-Fail…), sur un wd blue qui a moins de 3 mois :
```
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE                                         
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0                                                 
  3 Spin_Up_Time            0x0027   184   182   021    Pre-fail  Always       -       1766                                              
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       164                                               
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0                                                 
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0                                                 
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       825                  
```
    - [^] # Champs
      
      Posté par Arthur Accroc le 24 octobre 2013 à 13:44. Évalué à 3.
      
      Ce n’est pas forcément clair, mais « Old_age » et « Pre-fail » indiquent les types de valeurs. C’est-à-dire que quand les valeurs associées ne sont pas bonnes (et uniquement dans ce cas), c’est que le disque est usé ou prêt à tomber en panne.
      
      L’augmentation anormale de certaines valeurs peut indiquer un souci (comme le parquage des têtes trop fréquent), mais pas forcément inquiétant à court terme. Par contre, quand tu as quelque chose dans le champ WHEN_FAILED, il faut vraiment s’inquiéter !
      
      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Moi aussi je veux jouer

Posté par Marotte ⛧ le 23 octobre 2013 à 16:55. Évalué à 5.

Quand je fais un smartctl -a j'ai bien un 9 Power_On_Hours mais pas de N Load_Cycle_Count est-ce normal et dans ce cas pourquoi ?

Si je calcule Power_On_Hours/Power_Cycle_Count j'obtiens environ 6.6, puis-je en déduire (en considérant que ma machine utilise tout le temps ce disque) que ma machine est allumée pendant 6 heures et 36 minutes en moyenne ?
- [^] # Re: Moi aussi je veux jouer
  
  Posté par gnujsa le 23 octobre 2013 à 21:14. Évalué à 1.
  Mais c'est génial ça !
  Ça veut dire que l'on peut calculer l'uptime moyen comme comme ça:
```
$ sudo smartctl -a $(mount|grep '^/.*on / '|awk '{print $1}')|egrep '(Power_On_Hours|Power_Cycle_Count)'|awk '{print $10}'|tr '\n' '/'|sed 's/\/$/\n/'|bc -l

136.43205574912891986062
```
  et ainsi savoir qui a la plus grosse uptime moyen et qui va user ses disques le plus rapidement !
  - [^] # Re: Moi aussi je veux jouer
    
    Posté par M.Poil (site web personnel) le 24 octobre 2013 à 08:04. Évalué à -1.
```
   DiskStation> smartctl -a $(mount|grep '^/.*on / '|awk '{print $1}')|egrep '(Power_On_Hours|Power_Cycle_Count)'|awk '{print $10}'|tr '\n' '/'|sed 's/\/$/\n/'|bc-l
  -ash: bc: not found
```
    Désolé :D
    
    Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
    - [^] # Re: Moi aussi je veux jouer
      
      Posté par M.Poil (site web personnel) le 24 octobre 2013 à 08:11. Évalué à 1.
      eval $(smartctl -a /dev/sda |awk '/(Power_On_Hours|Power_Cycle_Count)/ { print $2"="$10 }' ); echo $(($Power_On_Hours/$Power_Cycle_Count))
      
      241
      
      Ca ne semble pas cohérent, j'ai dû éteindre mon NAS 5 fois en 4 ans, disons 10 si on compte les reboot pour maj du DSM
      
      Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
      - [^] # Re: Moi aussi je veux jouer
        
        Posté par phoenix (site web personnel) le 24 octobre 2013 à 09:21. Évalué à 3.
        
        Est-ce que les disques sont mis en veille ou reste toujours allumé ? Car au final, c'est l'uptime moyen du disque dur.
        
        [^] # Re: Moi aussi je veux jouer
        
        Posté par M.Poil (site web personnel) le 26 octobre 2013 à 22:15. Évalué à 1.
        
        En principe j'ai désactivé la mise en veille des disques
        
        Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
  - [^] # Re: Moi aussi je veux jouer
    
    Posté par benoar le 25 octobre 2013 à 00:27. Évalué à 1.
    Rhaa, mais faites du awk correct bon dieu !
```
sudo smartctl -a $(awk '$2 == "/" && $1 != rootfs { print $1 }' < /proc/mounts) | awk '$2 == "Power_On_Hours" { poh = int($10) } $2 == "Power_Cycle_Count" { pcc = int($10) } END { print poh / pcc }'
```
- [^] # Re: Moi aussi je veux jouer
  
  Posté par benoar le 25 octobre 2013 à 00:21. Évalué à 2.
  
  mais pas de N Load_Cycle_Count est-ce normal et dans ce cas pourquoi ?
  
  Les données SMART sont assez mal standardisées, et on n'a pas toujours tout. Tu as peut-être d'autres valeurs se rapprochant de cette signification ?
  
  Si je calcule Power_On_Hours/Power_Cycle_Count j'obtiens environ 6.6, puis-je en déduire (en considérant que ma machine utilise tout le temps ce disque) que ma machine est allumée pendant 6 heures et 36 minutes en moyenne ?
  
  Oui, si ton disque est allumé tout le temps quand ta machine l'est.
  - [^] # Re: Moi aussi je veux jouer
    
    Posté par Marotte ⛧ le 25 octobre 2013 à 00:43. Évalué à 2.
    Tu as peut-être d'autres valeurs se rapprochant de cette signification ?
    
    Non je crois pas, voilà ce que j'ai :
```
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   100   051    Pre-fail  Always       -       1
  3 Spin_Up_Time            0x0007   100   100   015    Pre-fail  Always       -       7040
  4 Start_Stop_Count        0x0032   097   097   000    Old_age   Always       -       3149
  5 Reallocated_Sector_Ct   0x0033   253   253   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   253   253   051    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0025   253   253   015    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       10945
 10 Spin_Retry_Count        0x0033   253   253   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0012   253   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       1655
 13 Read_Soft_Error_Rate    0x000e   100   100   000    Old_age   Always       -       12350589
187 Reported_Uncorrect      0x0032   253   253   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       1
190 Airflow_Temperature_Cel 0x0022   065   058   000    Old_age   Always       -       35
194 Temperature_Celsius     0x0022   133   112   000    Old_age   Always       -       35
195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       -       12350589
196 Reallocated_Event_Count 0x0032   253   253   000    Old_age   Always       -       0
197 Total_Pending_Sectors   0x0012   253   253   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   253   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x000a   100   100   000    Old_age   Always       -       0
201 Soft_Read_Error_Rate    0x000a   100   100   000    Old_age   Always       -       0
202 Data_Address_Mark_Errs  0x0032   100   100   000    Old_age   Always       -       2
```
    Oui, si ton disque est allumé tout le temps quand ta machine l'est
    
    Ça doit être le cas. Là avec un uptime de plus de 12 heures je suis maintenant à environ 6.61 \o/
    - [^] # Re: Moi aussi je veux jouer
      
      Posté par benoar le 25 octobre 2013 à 00:55. Évalué à 2.
      
      195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 12350589
      
      Avec ce genre de valeur qui ne veut rien dire, effectivement, c'est un disque nase qui ne file pas beaucoup d'info intéressante.
# Disques externes (ou tout est relatif)

Posté par Arthur Accroc le 24 octobre 2013 à 10:41. Évalué à 2. Dernière modification le 24 octobre 2013 à 10:43.
Le cas des disques externes est curieusement différent, surtout pour les non-ventilés.

Là un Western Digital Elements Desktop que j’ai mis au cul de ma box :
```
Model Family:     Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model:     WDC WD20EARX-32PASB0
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  4 Start_Stop_Count        0x0032   099   099   000    Old_age   Always       -       1051
  9 Power_On_Hours          0x0032   089   089   000    Old_age   Always       -       8278
193 Load_Cycle_Count        0x0032   199   199   000    Old_age   Always       -       4229
194 Temperature_Celsius     0x0022   125   104   000    Old_age   Always       -       25
```
Bien que ce soit un Green, le Load_Cycle_Count reste dans la limite du raisonnable (même si je préférerais pouvoir limiter encore sa progression).
C’est encore heureux, vu qu’il ne semble pas supporté par l’utilitaire de Western Digital, que ni hdparm -J ni idle3ctl ne réussissent à y accéder à travers l’interface USB, et que le boîtier n’est clairement pas fait pour être démonté.
À noter que la température maximale qu’il ait atteint est 46°C (il faut soustraire de 150 les valeurs des colonnes VALUE et WORST).

Là, un Seagate non ventilé (je ne retrouve plus le nom commercial et les modèles actuels sont un peu différents) que j’utilise pour faire des sauvegardes :
```
Model Family:     Seagate Barracuda 7200.14 (AF)
Device Model:     ST2000DM001-9YN164
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       496
190 Airflow_Temperature_Cel 0x0022   076   044   045    Old_age   Always   In_the_past 24 (0 24 24 20 0)
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       1839
194 Temperature_Celsius     0x0022   024   056   000    Old_age   Always       -       24 (0 18 0 0 0)
```
Le Load_Cycle_Count est assez élevé par rapport au nombre d’heures de fonctionnement. Heureusement, il a le bon goût de supporter à peu près hdparm -B (juste, s’il faut le refaire à chaque fois…).
Mais le pire, c’est la température (cette fois, il faut soustraire de 100 les valeurs des colonnes VALUE et WORST pour la ligne Airflow_Temperature_Cel, alors que pour Temperature_Celsius, elles sont directement lisibles.).
La première fois que je l’ai utilisé (c’était pour une opération assez longue), je l’ai trouvé chaud. smartctl a confirmé mes craintes : il est monté à 56°C !
Depuis, quand je fais une opération un peu conséquente avec, je mets un pain de glace dessus…
En plus, il réussit à être bruyant malgré l’absence de ventilateur.

Du coup, pour avoir un disque externe discret, je préfère sans hésiter le Western Digital : même si le disque utilisé est le moins fiable de la marque, il ira sûrement plus loin qu’un autre disque qui surchauffe…

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
- [^] # Re: Disques externes (ou tout est relatif)
  
  Posté par Marotte ⛧ le 24 octobre 2013 à 12:27. Évalué à 2.
  
  Depuis, quand je fais une opération un peu conséquente avec, je mets un pain de glace dessus…
  
  Gni ?! Je suppose que tu parles des blocs réfrigérants qu'on utilise généralement dans les glacières. Mais avec la condensation c'est humide non ? C'est pas dangereux ?
  - [^] # Re: Disques externes (ou tout est relatif)
    
    Posté par Arthur Accroc le 24 octobre 2013 à 13:52. Évalué à 2.
    
    Gni ?! Je suppose que tu parles des blocs réfrigérants qu'on utilise généralement dans les glacières.
    
    En effet.
    
    Mais avec la condensation c'est humide non ?
    
    Je mets le pain de glace dans un sac plastique, et une bonne partie de la condensation reste dedans. Le dessus du boîtier devient un peu humide, mais pas de là à ce que l’eau coule.
    
    C'est pas dangereux ?
    
    Ça n’est alimenté qu’en 12 V.
    Quant au danger pour le disque, de toute façon, c’est ça ou je finirai par le cramer par surchauffe…
    La bonne solution aurait été évidemment de ne pas acheter ce truc.
    
    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
- [^] # Re: Disques externes (ou tout est relatif)
  
  Posté par benoar le 25 octobre 2013 à 00:32. Évalué à 2.
  smartctl a confirmé mes craintes : il est monté à 56°C !
  
  Bah si t'es effrayé par ça…
```
194 Temperature_Celsius     0x0022   052   031   000    Old_age   Always       -       62 (Min/Max 12/69)
```
  et son copain à peine moins. Ce sont des Samsung, mais le NAS est placé dans un environnement plutôt fermé.
# Parquage insupportable.

Posté par Tanouky le 24 octobre 2013 à 13:55. Évalué à 2.

Je galère tout le temps pour réguler ces parquages de tête sous Debian et Archlinux. Cela fonctionne, puis une sortie de veille fout tout en l'air.

Je n'ai jamais réussi à faire quelque chose de viable, sauf lancer un cron toutes les 5 minutes histoire qu'après une sortie de veille, les têtes ne soient pas parquées toutes les 20 secondes.

Ça m'est insupportable d'entendre ce petit bruit qui égrène la vie de mon matériel. Et vraiment, sous Linux, je trouve que c'est la merde sur ça.
- [^] # Laptop Mode Tools
  
  Posté par Arthur Accroc le 24 octobre 2013 à 15:18. Évalué à 1.
  
  Pour ma part, je gère ce problème depuis longtemps avec les Laptop Mode Tools. Une fois configuré, ça te met le niveau de gestion d’énergie (hdparm -B) que tu veux pour ton disque, pour le fonctionnement sur secteur et sur batterie, au démarrage, à la sortie de veille, au changement de source d’alimentation…
  
  Par contre, un systemd plus loin, ça ne semble plus fonctionner correctement. Soit que systemd ne le lance pas au bon moment, soit qu’il fasse sa propre tambouille avec les disques tellement il va bientôt remplacer tout le système…
  
  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
  - [^] # Re: Laptop Mode Tools
    
    Posté par Tanouky le 25 octobre 2013 à 08:54. Évalué à 1.
    
    Je gère aussi avec laptop-mode-tools, mais que ce soit avec sysvinit (Debian) ou systemd (Archlinux), je ne suis jamais parvenu à rendre cette gestion parfaite.
    
    J'ai mis ça sur le compte du noyau et de mon incompétence, mais en attendant, c'est resté très pénible à l'utilisation.
    
    Je te remercie cependant du conseil. :)
# Le problème n'est pas nouveau

Posté par NilugeKiWi le 24 octobre 2013 à 14:03. Évalué à 4.

Ça m'était arrivé il y a plusieurs années avec un vieux FreeNAS et un disque 300Go de chez Maxtor suite à un mauvais réglage dans FreeNAS. Le disque est mort au bout d'un an d'uptime, je n'ai hélas plus les données SMART exactes.

En parlant de serveur NAS, outre les Synology avec firmware ouverts, Netgear a depuis cette année une gamme de produits fort intéressants: les ReadyNAS. Ils ont des modèles 2, 4 et 6 baies. Le moins cher: ReadyNAS 102 (actuellement à 140€ sur amazon mais il était temporairement disponible à 100€ chez topachat il y a quelques semaines…).

Le hardware est bien fichu, bien plus compact et pratique que ce qu'on pourrait obtenir avec des composants PC standards. CPU ARM, 512Mo de ram, disques durs démontables à chaud, sans outils, O vis, plusieurs ports usb (2 et 3), et port esata, réseau 1Gbps.

Le software est hélas propriétaire, mais la bonne nouvelle c'est que ça reste ouvert: ils ont un app store ouvert (et gratuit il semblerait), mais surtout en 2 clics on peut activer l'accès ssh root.
Et là on découvre que c'est une debian Wheezy, avec un dépôt apt netgear hébergé sur amazon S3 pour leur software, et qu'ils utilisent btrfs pour stocker les données sur les disques internes, le tout avec un kernel linux 3.0.
J'ai été surpris d'apprendre qu'il y a du btrfs dans la nature depuis avril 2013 comme ça.
Du coup ils proposent des snapshots réguliers, avec auto nettoyage des plus vieux, tout en gardant des vielles versions de temps en temps, le tout avec une interface web bien fichue pour explorer ça et restaurer un fichier particulier ou un répertoire, ou revenir complètement en arrière sur un volume entier.
- [^] # Avril
  
  Posté par Arthur Accroc le 24 octobre 2013 à 14:19. Évalué à 4.
  
  J'ai été surpris d'apprendre qu'il y a du btrfs dans la nature depuis avril 2013 comme ça.
  
  Quelqu’un a dû leur dire le 1ᵉʳ du mois que BTRFS était prêt à être utilisé en production…
  
  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
- [^] # Re: Le problème n'est pas nouveau
  
  Posté par benoar le 25 octobre 2013 à 00:36. Évalué à 2.
  
  Oui enfin le mieux c'est quand même de choisir un NAS qui supporte une vrai Debian dès le début ! Voir par exemple la page de Martin Michlmayr http://www.cyrius.com/debian/
  
  Du coup, ça démystifie beaucoup le truc et ça devient « normal » d'avoir un ordi comme un autre avec une Debian, sur lequel tu peux installer toute la logithèque Debian, même si c'est un armel et qu'il consomme 5W…
  - [^] # Re: Le problème n'est pas nouveau
    
    Posté par NilugeKiWi le 25 octobre 2013 à 16:00. Évalué à 2.
    
    Mais justement c'est une vrai debian dès le début. Avec une couche proprio au dessus pour avoir une belle interface web, mais c'est tout.
    Il y a potentiellement quelques drivers pas libres tout au plus, j'ai pas été vérifier ça.
    
    L'intérêt principal pour moi pour cette machine c'était son prix: à 100€ il est difficile faire quelque chose d'équivalent, qui est toujours utilisable par Madame Michu, et bidouillable par ssh. Certains NAS sont moins cher mais complètement fermés, d'autres sont plus ouverts (Synology, firmware libre) mais plus cher. C'était un bon compromis pour moi.
    - [^] # Re: Le problème n'est pas nouveau
      
      Posté par benoar le 28 octobre 2013 à 11:31. Évalué à 2.
      
      Mais justement c'est une vrai debian dès le début. Avec une couche proprio au dessus pour avoir une belle interface web, mais c'est tout.
      
      OK. Mais le support de cette plateforme est-il intégré upstream chez Debian ? C'est plutôt de ça dont je parlais. Car les installations de Debian « ad-hoc » pour les NAS, il y en a plein (voire de simples chroot…). Mais dans la durée, ça ne tient pas, car il n'y a aucun support des versions suivantes.
      
      Il y a potentiellement quelques drivers pas libres tout au plus, j'ai pas été vérifier ça.
      
      Ah, on arrive encore aux merdes classiques… mauvais point pour Synology, qui m'a plutôt impressionné avec ton histoire, quand même.
      
      L'intérêt principal pour moi pour cette machine c'était son prix: à 100€ il est difficile faire quelque chose d'équivalent, qui est toujours utilisable par Madame Michu, et bidouillable par ssh. Certains NAS sont moins cher mais complètement fermés, d'autres sont plus ouverts (Synology, firmware libre) mais plus cher. C'était un bon compromis pour moi.
      
      Oui, je comprends que le rapport utilité/prix est vraiment pas mal. Moi je table sur l'occasion pour avoir des prix corrects ;-)

# merci!

Posté par riba le 27 octobre 2013 à 17:53. Évalué à 2.

2 WD "Green" dans mon NAS avec:

193 Load_Cycle_Count        0x0032   041   041   000    Old_age   Always       -       478954
193 Load_Cycle_Count        0x0032   028   028   000    Old_age   Always       -       518939

sortis du NAS, 2 coups de idle3ctl et tout va mieux!

Suivre le flux des commentaires

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