Cher vendredi,
j'ai envie de te raconter une courte histoire que tu trouveras peut-être tout aussi hallucinante que moi.
Pour l'introduction, mon ordinateur est depuis deux ans équipé d'un SSD de marque Crucial. Il remplace bien avantageusement le disque dur d'origine au niveau des performances, à tel point que parfois un programme peut remplir le swap tranquillement sans que je le remarque.
Il y a une quinzaine de jours, j'ai commencé à avoir des soucis de stabilité sur l'ordinateur. Les symptômes ressemblaient à une perte de disque, un peu comme un faux contact. Le noyau passait alors d'urgence les volumes en lecture seule, et seuls les fichiers déjà en cache restaient accessibles. Rien à faire pour remettre le tout en bon ordre, un redémarrage était nécessaire. Ce redémarrage résolvait le problème pour un temps (et permettait de tester la fiabilité du système de fichiers pour les coupures brutales).
Après avoir cherché pendant longtemps la cause (ouverture de l'ordinateur, nettoyage des contacts, retour sur un noyau plus vieux car je venais de le mettre à jour, etc), j'ai trouvé la réponse grâce à mon moteur de recherche à travers un sombre forum : j'étais victime du bug des 5184 heures.
Contrairement aux apparences, ce n'est pas le titre d'un film d'horreur mais un bug bien réel. Sa description par le fabricant est :
Correct a condition where an incorrect response to a SMART counter will cause the m4 drive to become unresponsive after 5184 hours of Power-on time. The drive will recover after a power cycle, however, this failure will repeat once per hour after reaching this point.
En résumé, après 5184 heures d'utilisation, vous n'avez plus l'autorisation d'utiliser votre matériel pendant plus d'une heure de façon continue. On peut y voir de l'incompétence, mais comme on est vendredi je me pose quelques questions :
* Pourquoi le site officiel du fabricant n'en fait pas mention sur son site ? Le changelog n'est disponible que pour la dernière version publiée. Ne vous fiez pas à « Additional details can be found in the firmware guide », c'est faux. Pour avoir une idée du changelog complet depuis la version X, il faut se taper à la main une série de page sur des forums (si vous êtes curieux j'ai reconstitué le tout ici)
* Pourquoi s'amuser à avoir des numéros de version incompréhensibles ? Mon SSD était en version 0009. La suivante est 0309, puis 000F, puis 010G. Faut-il deviner tout seul que 0309 veut dire « mise-à-jour indispensable » ?
* Combien d'utilisateurs normaux vont vraiment trouver cette information avant de mettre le disque à la poubelle et en racheter un ? On est en plein dans de l'obsolescence programmée (même si c'est involontairement, le code fait ce qu'on lui dit).
Le bug est tellement trivial (une panne pour une incrémentation de compteur SMART, sérieusement ?) qu'il n'est même pas possible de critiquer toute cette intelligence du firmware qui serait bien mieux dans le noyau. Quand on regarde le changelog, il y aurait pourtant beaucoup à dire. Existe-t-il des SSD « propres », qui font leur boulot de stockage de données et laissent le noyau faire le reste ?
Au passage, si quelqu'un a une explication technique pour le 5184, je suis preneur. Ce n'est pas une puissance de 2, mais correspond à 3 au cube multiplié par 2 puissance 6.
# trim ?
Posté par fredix . Évalué à 1.
Peut etre un rapport avec l'option TRIM qui n'est pas activée par défaut http://doc.ubuntu-fr.org/ssd_solid_state_drive#trim ?
Sans cette option il me semble que le disque est beaucoup plus lent et sa durée de vie est raccourcie.
[^] # Re: trim ?
Posté par Florent Fourcot . Évalué à 4.
A priori non, je fais régulièrement des TRIM, et mon disque remarche parfaitement après la mise à jour du fabricant.
Et tant bien même sans TRIM. Ça pourrait provoquer une mort lente de certaines parties du disque, pas une déconnexion brutale de la liaison disque <-> OS.
[^] # Re: trim ?
Posté par Jiehong (site web personnel) . Évalué à 4.
Tu veux dire qu'une mise à jour à réglé le souci ?
[^] # Re: trim ?
Posté par Thom (site web personnel) . Évalué à 2.
Une mise à jour du firmware sans doute.
Mon SSD crucial m'a aussi causé quelques soucis.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
# bug firmware
Posté par olivier_h . Évalué à 10.
C'est simplement un bug firmware, pas de l'obsolescence programmée…
Le truc c'est qu'il est connu et a fait beaucoup de bruit il y a 1 ans et demi (début 2012), du coup c'est peut être plus complexe de trouver l'information maintenant surtout vu la sortie de nouvelles versions de ssd.
[^] # Re: bug firmware
Posté par Renault (site web personnel) . Évalué à 10. Dernière modification le 18 octobre 2013 à 11:22.
Rappelons en effet la définition d'obsolescence programmée : il s'agit d'un sabotage volontaire pour réduire la durée de vie d'un produit.
La mauvaise qualité du produit (pour baisser les coûts), les erreurs de conception ou encore les bogues dans un programme n'en sont pas uns. La preuve, une mise à jour officielle corrige le problème.
Je pense qu'il faut arrêter d'employer cet expression dès qu'un produit meurt vite…
EDIT : concernant le noyau, il n'est pas censé tout faire non plus. Les disques durs, les cartes graphiques et autres font plein de choses à la place du noyau qui délègue certaines choses trop spécifiques au profit d'entrées/sorties plus standards via les firmwares.
Ce n'est pas toujours une bonne chose, loin de là, mais les SSD sont loin d'être les seuls composants concernés.
[^] # Re: bug firmware
Posté par Florent Fourcot . Évalué à -1. Dernière modification le 18 octobre 2013 à 11:25.
Vous avez peut-être loupé la partie « On peut y voir de l'incompétence, mais comme on est vendredi […] ».
C'est pour moi une vraie question pour un jour pareil. Sur la notion de bug, on a que la parole du constructeur. La présence d'un correctif ne prouve rien, vu que je doute de la proportion d'utilisateurs qui vont vraiment en bénéficier.
En tout cas, un constructeur capable de mettre en panne en disque en faisant un +1 sur un compteur, j'ai du mal à lui faire confiance pour mes données…
[^] # Re: bug firmware
Posté par Renault (site web personnel) . Évalué à 10.
Des bogues stupides à plusieurs millions d'euros et avec des vies humaines, on en connait tu sais dans l'Histoire de l'informatique. Parfois c'est juste une erreur de conversion d'unité, un élément manquant dans la syntaxe, un problème de conception, un changement de matériel qui change la plage de valeurs des données provoquant un comportement indéfini, etc. Est-ce pour autant que la NASA, l'ESA ou leurs sous-traitants sont des gros mauvais incompétents à qui on ne fait plus confiance pour lancer des engins dans l'espace ? Clairement, non, une erreur peut arriver.
L'autre jour, une carte graphique a prit feux sous mes yeux de AMD, est-ce pour autant qu'ils sont incompétents et que leurs cartes graphiques sont dangereuses ? Non…
Bref, si tu veux on peut lister un nombre colossal de produits chers ou pas ayant eu un défaut important plus d'une fois. Et la majorité d'entre eux s'explique uniquement par l'incompétence (ou une erreur bête). La théorie du complot, très peu pour moi.
[^] # Re: bug firmware
Posté par Florent Fourcot . Évalué à 1.
Des bugs stupides arrivent quotidiennement oui. Mais habituellement, les constructeurs que je juge fréquentables mettent en avant sur leurs sites les correctifs. J'aurais attendu un message explicite sur le site de support de Crucial : « attention, votre SSD de modèle X est victime de ce bug, voici le correctif ».
Le correctif est en effet ancien, mais le bug va continuer de toucher des utilisateurs pendant des mois, voir années. Un autre utilisateur ayant commandé le même modèle le même jour que moi a encore 2000 heures devant lui avant d'atteindre le bug, il y a pour moi un devoir de communication à ce sujet sur la durée. S'ils ne le font pas, ils transforment le bug en une mise à la poubelle.
[^] # Re: bug firmware
Posté par Renault (site web personnel) . Évalué à 7.
Et si les derniers modèles embarquent déjà le correctif ? C'est une pratique courante de faire les mises à jour des produits dans la chaine de production quand il y en a.
Comme tu ne el sais pas, tu juges peut être hâtivement.
De plus, des entreprises qui cachent les problèmes sous le tapis, elles sont nombreuses. Cela ne signifie pas qu'ils sont incompétents ou qu'ils sabotent les produits, mais qu'ils sont négligents vis à vis des clients ce qui est un autre problème.
[^] # Re: bug firmware
Posté par Troy McClure (site web personnel) . Évalué à 5.
C'est vrai qu'on un peu l'impression que les constructeurs de SSD traitent tout ça un peu par-dessus la jambe, la qualité du firmware, le suivi des updates de firmware, les gens qui leur font confiance pour leur confier quelques précieuses données. C'est quand même un peu malheureux étant donné le coté "crucial" de tout ça. Tous les constructeurs de ssd ont eu des merdes hallucinantes avec des disques qui perdent les données , qui les corrompent etc. Du temps des disques dur c'était quand même drolement plus simple. Soit c'est super chaud d'ecrire un firmware de ssd , soit c'est des gros manches qui feraient bien de faire quelques tests unitaires sur leur firmwares moisis.
[^] # Re: bug firmware
Posté par Prosper . Évalué à 6.
Tu veux qu'on parle des Western Digital et de leur support du TLER ?
[^] # Re: bug firmware
Posté par deasy . Évalué à -1. Dernière modification le 03 novembre 2013 à 04:42.
J'ajoute ceci, AMD ne fait pas de carte vidéo.
Ils concoivent un gpu et également un pcb de référence.
Après ce sont les fabricants de carte qui choisissent de le suivre ou pas, de revoir les composants à la baisse(en qualité) ou à la hausse.
[^] # Re: bug firmware
Posté par olivier_h . Évalué à 5.
Le firmware a été déployé très rapidement sur les unités mis en vente après la découverte du bug.
Dis toi que tu as du bol, l'application de firmware sur les crucial est non destructif (ce qui ne pas le cas chez tous les concurrents).
[^] # Re: bug firmware
Posté par saltimbanque (site web personnel) . Évalué à 6.
a priori oui, mais si une marque dédie tout son budget au marketing et rien aux tests, je le range volontiers dans "durée de vie limitée des produits vendus en toute connaissance de cause". l'obsolescence n'est pas programmée au sens de volontaire, elle est programmée au sens de "connue", programmée par le fait qu'il n'y ait aucun effort consacrée à la durée de vie.
Le raisonnement peut paraitre de mauvaise foi, pointilleux, etc… ; il ne l'est pas : pour une marque de qualitay, vendre des produits DURABLES doit représenter de gros efforts.
Le client participe à cette obsolescence là (si ce n'est : "engendre cette obsolescence"), en achetant des produits cool-pas-chers-et-pas-testé avec joie, forçant donc les entreprises à privilégier le marketing sur le reste pour rester dans la concurrence.
[^] # Re: bug firmware
Posté par maboiteaspam . Évalué à -4.
Vas y, si t'as de l'argent en trop je veux bien quêter.
Bref, c'est pas au client de définir la marche de conduite d'une entreprise par les desiderata de son comportement, qui en réalité ne sont que le fruit d'une certaine réalité du partage des richesses, mais bien à une certaine collectivité étatique qui est censé maintenir l'ordre et le pouvoir par sa majorité…
[^] # Re: bug firmware
Posté par ckyl . Évalué à 10.
Je pense que le message était justement qu'acheter "pas cher", lire clairement en dessous du tarif admis pour avoir quelque chose de fonctionnel et robuste, coûte souvent très cher sur le long terme. Comme on dit Je suis trop pauvre pour acheter bon marché.
N'importe quoi. Si les gens veulent acheter n'importe quoi à partir du moment ou c'est pas cher, on leur fabrique et on leur vend. Il suffit d'aller voir eBay…
À partir du moment ou les gens font du prix le seul critère prédominant, il y a un risque de tirer tout le marché vers le bas même ceux qui à l'origine cherchaient à produire un bon rapport qualité/prix.
Maintenant ça ne veut pas dire que cher implique systématiquement qualitatif, très loin de là. Mais à un moment à vouloir toujours tirer sur le prix, on ne peut avoir que de la merde… Et ça c'est toi qui le choisi, pas besoin de théorie du complot.
[^] # Re: bug firmware
Posté par Prosper . Évalué à 10.
Même pas, j'ai souvenir que smart m'a bien dit de mettre à jour le firmware, faut juste pas oublier de mettre à jour la base smart si c est pas déja dans la cron ( update-smart-drivedb met à jour le fichier /usr/share/smartmontools/drivedb.h ) dans lequel on trouve bien comme message :
This drive may hang after 5184 hours of power-on time:
http://www.tomshardware.com/news/Crucial-m4-Firmware-BSOD,14544.html
See the following web pages for firmware updates:
http://www.crucial.com/support/firmware.aspx
http://www.micron.com/products/solid-state-storage/client-ssd#software
Bref encore une utilisation bien moisie de l'expression obsolescence programmée
[^] # Re: bug firmware
Posté par Florent Fourcot . Évalué à -3.
Mon
smartctl -a /dev/sdane donnait rien. J'ai peut-être loupé un morceau… Ou alors il y a d'autres options à utiliser ?Après c'est vrai que les utilisateurs normaux consultent souvent smart quand leurs ordinateurs plantent. J'ai l'impression de vivre sur une autre planète quand je lis cette réponse.
[^] # Re: bug firmware
Posté par Prosper . Évalué à 1.
Oui il faut mettre la base à jour comme je l'ai dit précédemment
Les vrais gens enregistrent leur produit auprès du constructeur, qui envoie une communication pour ce genre de bug , tu n'as fait ni l'un ni l'autre.
Je vois pas ce que tu voudrais d'autre , y a eu communication sur 150000 sites , tu voudrais quoi ? que crucial devine tout seul que tu leur a acheté un produit et t'envoies un mec avec des roses en te disant que t es susceptible d'avoir un soucis sur ton SSD ?
Bref si j'etais méchant je dirais que tu n'as qu'a t'en prendre qu'à toi même.
[^] # Re: bug firmware
Posté par Florent Fourcot . Évalué à 4.
Et beh, on connaît pas les mêmes vrais gens.
Que crucial l'écrive sur son site de support du produit, c'est trop demander ?
[^] # Re: bug firmware
Posté par Prosper . Évalué à 2.
Les vrais gens consultent régulierement les site des constructeurs , tu blagues là non ?
[^] # Re: bug firmware
Posté par CHP . Évalué à 8.
pas besoin de consulter regulièrement, seulement quand on a un problème.
Et oui, ca parait logique quand t'as un problème d'aller voir sur le site du constructeur
[^] # Re: bug firmware
Posté par Prosper . Évalué à 1.
Généralement et puisqu'on parle des gens normaux, on tape directement son moteur de recherche préféré et là on a la réponse. Bref, vous pinaillez.
[^] # Re: bug firmware
Posté par Maclag . Évalué à 3.
C'est en fait une excellente idée: ça devrait être accessible via une bonne interface graphique des familles.
En ce qui concerne les changelogs, j'ai le même problème avec les Seagate que j'ai possédés: il y a bien notification que de nouveaux firmwares sont dispos, mais pour savoir ce qu'ils changent, tu peux toujours te brosser…
[^] # Re: bug firmware
Posté par navaati . Évalué à 2.
C'est le cas sous gnome (logiciel Disks).
[^] # Re: bug firmware
Posté par deasy . Évalué à 0.
Je plussoie on en a largement parlé sur les sites de matériel coté francophone(hardware.fr par exemple)
# SSD « propres » ?
Posté par Jiehong (site web personnel) . Évalué à 2.
D'ailleurs, je voudrait bien savoir ce qu'il en est actuellement : le trim, ou l'équi-répartition des données au sein du disque est-il préférablement pris en charge par le noyau ou le disque ?
Le trim constructeur est-il à favoriser sur celui du noyau (pour btrfs ou ext4 par exemple) ?
[^] # Re: SSD « propres » ?
Posté par Prosper . Évalué à 7.
J'ai vu plusieurs articles qui déconseillent de trimer directement dans les options de montage ( avec l'option discard ) et qui préconisent plutôt de lancer la commande fstrim régulièrement ( ou un moment ou y a peu d I/O tant qu'à faire) parce que sinon à chaque fois que l'OS efface un fichier il prévient le SSD pour que celui ci efface la ou les cellules impactées ce qui est pénalisant sur les I/O , d'ailleurs il me semble que windows8 contrairement à 7 gère lui aussi le trim de cette façon.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SSD « propres » ?
Posté par Oliver (site web personnel) . Évalué à 3.
Le
discarddu/etc/fstabpeut ralentir l'effacement de fichier :Par contre, le wiki d'Arch Linux recommande d'ajouter
discarddans/etc/fstab. Du moins, si l'effacement de fichier n'est pas plus lent :Donc avant de choisir (
discardoufstrim), mieux vaut tester son SSD spécifique. A moins, que cette page Arch Linux se trompe… (qui veut bien mettre à jour cette page wiki ?)Remarquons que plus bas (ext4) sur cette même page, les deux possibilités sont rappelées (mais la possibilité
fstrimest en parenthèses) :Qui a déjà réalisé ce genre de tests ?
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
[^] # Re: SSD « propres » ?
Posté par benoar . Évalué à 1.
Les soit-disant « problèmes » évoqués sont juste que discard fait effectivement très bien son boulot : il dit au SSD qu'il peut supprimer ce bloc, et donc oui, forcément, si tu veux le récupérer après un "rm" mal placé, bah tu peux pas, et oui si tu veux être discret sur les zones effacées ou non de ton disque pour des raisons de confidentialité (disque entièrement chiffré), il ne faut pas l'utiliser. Mais désolé, ce sont deux cas d'utilisation très spécifiques et le discard marche très bien pour tout le monde dans 99,9% des cas.
Là où le discard est intéressant, c'est pour la durée de vie du SSD et les perfomances : ça les améliore, car il a moins besoin de refaire de la réécriture interne pour trouver de la place. Perso, je pense que les chiffres classiques d'amplification d'écriture sont souvent beaucoup sous-estimés car ils ne prennent pas en compte une charge classique mais très mauvaise pour les SSD : plein de petites écritures aléatoires. Après, un FS peut mitiger le problème en essayent d'être « gentil » avec le disque à ce niveau, cf par exemple l'option "ssd" (voire ssd_spread pour les contrôleurs vraiment merdiques, i.e. les cartes CF/SD / clé USB, mais faut être un peu maso) de btrfs.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SSD « propres » ?
Posté par benoar . Évalué à 2.
Franchement, se baser sur l'avis d'un mec qui a mis ça dans le wiki… Sans sources, ça me semble exagéré de dire ça. Et ça omet complètement les problèmes d'usure que ça entraîne de ne pas le faire.
WTF ? Soit je n'ai pas compris ce que tu dis, soit tu n'as pas compris le fonctionnement du trim… Bien sûr qu'il sera toujours très utile, et pas que pour les SSD (en virtualisation c'est pratique pour avoir des volumes sparse).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 23 octobre 2013 à 09:32.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SSD « propres » ?
Posté par benoar . Évalué à 3.
Tout à fait. Vu qu'on s'en fout de la localité des accès sur un SSD, ce genre de fonctionnement n'est de plus pas pénalisant pour les SSD, contrairement aux disques classiques.
Alors là pas du tout.
Mettons-nous dans le cas d'un SSD « complètement utilisé » (pas neuf) sans trim, i.e. sur lequel on a écrit au moins autant que sa capacité, et qui a donc tous ses secteurs marqués comme « occupés », quoiqu'en dise le FS dessus (même avec 100% d'espace libre) ; cas on ne peut plus classique pour un support de stockage utilisé normalement. Sa table (interne) de mapping des secteurs est faite d'une certaine manière, propre à sa manière de gérer la répartition des blocs et à l'utilisation qui en a été faite, et n'est pas forcément du tout contiguë par rapport aux secteurs tels qu'on les voit à plus haut niveau.
Quand une écriture pour le secteur S arrive, quel que soit la manière du FS d'écrire dessus, qu'il fasse du CoW ou autre, ton SSD va devoir trouver de la place pour l'écrire, à un endroit qui n'est pas le même que le précédent secteur qu'il remplace si c'est un FS style CoW, certes, mais de toute façon d'une manière où le SSD va devoir lui aussi changer son mapping car il y a beaucoup de chances qu'il doive déplacer tout un bloc (= plusieurs Mo) d'un endroit à un autre, en re-déplaçant d'autres secteurs au passage (= ré-écriture d'autres blocs également) afin de faire de la place (rappelons qu'il n'a plus de place libre, et qu'il doit donc trouver un endroit ou écrire = un bloc vierge dans son espace provisionné pour, dans lequel passera le secteur qui était précédemment présent à cet endroit selon le mapping du SSD). Tu n'as aucun contrôle sur le mapping interne du SSD, et même si tu voulais être optimiste et te dire qu'en faisant des écritures de la taille de « l'unité » qu'il utilise pour gérer son truc, ça serait « optimal », bah aujourd'hui les blocs c'est plusieurs Mo… (oui, il écrit par page, i.e. plusieurs centaines de Ko, mais je parle en erase-block pour simplifier)
Alors après, si ton contrôleur de SSD est pas trop con, il va pouvoir « agglutiner » plusieurs requêtes en écriture (tout en faisant gaffe à l'interaction avec la sémantique d'atomicité (ou pas) de la suite d'instructions qu'il reçoit) afin d'écrire des blocs plus gros, qui nécessiteront de moins faire de déplacement de secteurs, mais ça n'empêche qu'au final, la logique de garbage collection est au contraire beaucoup plus intense et compliquée, et ton amplification en écriture (= rapport de la taille de la requête en écriture / écritures réellement réalisées sur le SSD) est énorme, ce qui entraîne une dégradation de la durée de vie de ton SSD.
Je ne comprends pas ce que tu veux dire… tu parles d'un « reset » qui serait ton fstrim, mais fait régulièrement / automatiquement ?
Pour moi ça ne change pas tant que ça des FS modernes ; il y a la même problématique de répartition en dessous (sur le SSD).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SSD « propres » ?
Posté par benoar . Évalué à 2.
Bah, ce que je te décris c'est la situation avant le TRIM, et le fait d'être « vide mais néanmoins plein » ça ne dépend pas que d'une implémentation « buggée » du trim, mais également de sa non-implémentation. Bref, un trim bien implémenté (comme il l'est sur pas mal de SSD quand même, perso je n'ai jamais eu de problème même si ma base de test est faible) ça ne pose pas de problème.
Moi aussi je voulais ça à une époque et j'ai arrêté de rêver depuis. Ça n'arrivera jamais, car les vendeurs de Flash sont trop contents de vendre 3 fois plus cher leurs puces de Flash en les accompagnant d'un contrôleur pas cher + du soft proprio qui leur permet de segmenter le marché comme ils veulent. Car oui, aujourd'hui les vendeurs de SSD (donc y compris le contrôleur, qui est de toutes façons un ARM dans 99% des cas) sont des fabricants de mémoire. Accessoirement, ça évite les implémentations pourries en soft du wear-leveling (OK, au début tu retrouves des implémentations pourries en « hard », ce qui est… différent).
Et regarde du côté du futur, qui est NVM Express : on reprend les même commandes SCSI et on recommence. Tout ce qu'ils ont changé, c'est le bus en support (du PCIe direct vers le SSD au lieu d'un HBA AHCI qui cause SATA) et quelques suppressions de restrictions sur le nombre de queues, la gestion des interruptions, etc. Bref, c'est juste pour avoir des perfs meilleures, mais le paradigme « je suis juste une suite de secteurs consécutifs sans aucune distinction et aucun contrôle » reste. Remarque, ça aurait demandé un sacré changement niveau soft, qui est assez limité pour NVM Express. Et plus de rapidité, ça se vend bien, alors que plus de longévité… tu veux qu'ils vendent moins de disques, c'est ça !? Tueur de marché !
Tu imagines sur le marché des disques « dumb SSD » avec une étiquette « attention, à n'utiliser qu'avec un OS version X.Y blah blah ». Déjà que le passage aux secteurs 4k a l'air de faire peur à beaucoup de monde, là je n'imagine même pas.
Et sous Windows ? Pas d'implém windows = ça ne se fera pas.
Bah, même les CF bas de gamme s'amusent quand même à wear-leveler juste un secteur (ou un peu plus, peut-être) : celui de la FAT du FAT32… Et même s'ils sont très débiles, franchement c'est de la merde à l'utilisation, je ne sais pas comment ils font. Ah si, le contrôleur (qui ne fait pas grand chose) est tout merdique, et c'est parce que de toutes façon ils ne feront même pas d'effort pour enlever cette histoire de gestion de FAT32, juste parce que le prix en R&D doit être à peu près zéro, vu le prix proposé au public.
Bah, c'est mieux que rien. Franchement, l'accès raw n'arrivera jamais selon moi, ça changerait trop la sémantique de SCSI, et le jour où on se séparera de SCSI… et donc, le TRIM, c'est la seule solution pour bosser avec ce paradigme. Et elle n'est pas si mal, et conceptuellement propre. Reste aux constructeurs de SSD à faire des implém correctes, mais perso je n'ai pas eu de problème : tu devrais peut-être changer de constructeur.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 29 octobre 2013 à 07:51.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SSD « propres » ?
Posté par benoar . Évalué à 3.
Et quand tu switches de l'un à l'autre, qu'est-ce qu'il se passe ?
Après, je joue l'avocat du diable mais j'aimerais effectivement que ça soit possible. Mais je t'ai exposé mes arguments sur les raisons du peu d'espoir que j'ai…
Perso, je m'intéresse un peu aux SSDs, et je n'ai jamais entendu parler de problèmes sur le TRIM. Je veux bien croire qu'il y en a eu à un moment, mais pour que tu conseilles ainsi de se passer de TRIM, là, ça me semble exagéré.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SSD « propres » ?
Posté par benoar . Évalué à 2.
Heu… un problème de firmware sur un SSD d'il y a quatre ans et qui a été le premier (de mémoire) à implémenter le TRIM ? Houa, génial comme argument pour discréditer le TRIM.
Oui, il y a quelques problèmes de firmware parfois, sur plusieurs aspects y compris le TRIM, surtout chez les constructeurs pas consciencieux, mais de la à dire que le TRIM « est trop problématique à plein de niveau », tu exagères beaucoup.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 30 octobre 2013 à 16:29.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SSD « propres » ?
Posté par benoar . Évalué à 4.
OK, excuse pour l'homme de paille, je suis remonté un peu loin dans le thread sans réfléchir. Mais…
… je t'ai montré en quoi je pensais que ça n'arriverait pas. Donc, en « attendant », le TRIM est indispensable et est quelque chose qui marche plutôt bien. CQFD.
[^] # Re: SSD « propres » ?
Posté par deasy . Évalué à 0. Dernière modification le 04 novembre 2013 à 02:21.
Alors commençons par cette histoire de problèmes avec Intel et Crucial…
C'est la même chose, Crucial et Intel sont ensemble(imft), d'ailleurs pas mal de SSD du marché sont des clones, il y a peu d'originalité( de différence et de concurrence)…
Pour ce qui est des problèmes de firmware, oui les années précédentes ont eu leurs lots de problème mais il y a eu des mise à jour et depuis ce temps là les ssd sont devenu plus fiables.
Je plussoie :)
[^] # Re: SSD « propres » ?
Posté par Prosper . Évalué à 3.
Personne n'a écrit de pas faire de trim , mais de le faire autrement.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il faut arrêter de raconter des conneries
Posté par Florent Fourcot . Évalué à 0. Dernière modification le 18 octobre 2013 à 12:08.
Non pas sur le site, sur leur forum, même pas épinglé en haut de la rubrique !
Je me suis probablement fourvoyé alors dans la façon de présenter les choses. Et si un modérateur pense que le mot obsolescence programmée dépasse le degré d'humour autorisé, qu'il hésite pas à corriger. Mais sur le contenu du journal :
- Le disque tombe-t-il en panne après 5184 heures ?
- L'information est-elle présente sur la page du support du fabricant pour le produit ?
Je ne vois pas ce qui est diffamant là-dedans.
Et j'ignorais pour LDLC, ce qui enlève effectivement une bonne part de mes critiques. Il semblerait que par mon circuit de distribution, il y a eu de la perte de paquets.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il faut arrêter de raconter des conneries
Posté par dyno partouzeur du centre . Évalué à 0.
Clair, c'est juste un bug, ça n'a a priori rien de délibéré et volontaire.
Je serais crucial, je lui collerais les avocats au cul.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il faut arrêter de raconter des conneries
Posté par eingousef . Évalué à 2.
C'est vrai que vu la pertinence de tes commentaires, on peut pas dire que tu sois crucial.
*splash!*
[^] # Re: Il faut arrêter de raconter des conneries
Posté par Marotte ⛧ . Évalué à 0.
Peut-être mais tu ne peux pas l'affirmer, l'obsolescence programmée est une réalité, on peut donc sincèrement se poser des questions. D'autant que c'est de notoriété publique pour les imprimantes par exemple qu'il y a ce genre de compteurs, dont l'utilité technique est plus que douteuse.
216 jours d'utilisation et hop, inutilisable en l'état, si c'est de l'incompétence ça leur fera une bonne pub tiens…
Par contre, je me demande si ce compteur ne pourrait pas être remis à zéro avec un utilitaire ? Une heure de fonctionnement ça laisse le temps de passer deux ou trois commandes.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il faut arrêter de raconter des conneries
Posté par Larry Cow . Évalué à 2.
Faire racheter des consommables plutôt que de laisser le client les re-remplir lui-même, c'est peut-être comportement dégueulasse d'un point de vue commercial (et encore, il faudrait voir le nombre de clients qui feraient marcher la garantie pour une imprimante rendue inopérante par un "refill" d'encre pas prévue pour), mais c'est très très loin de l'obsolescence programmée. Qui, je le rappelle, concerne le fait de rendre un matériel volontairement moins durable pour forcer le remplacement. Ici, on interdit un moyen de faire durer le matériel (un consommable, en plus, et pas le matériel lui-même) plus longtemps que prévu.
C'est moche, ça fait chier. Mais ça n'est pas de l'obsolescence programmée. Affirmer que c'est une réalité, c'est de l'ordre de l'incantatoire.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5. Dernière modification le 19 octobre 2013 à 00:16.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il faut arrêter de raconter des conneries
Posté par oinkoink_daotter . Évalué à 9.
Si, en l'espèce on peut l'affirmer. Un constructeur qui délibérément mettrait une limite de fonctionnement à 5184 heures de fonctionnement de manière délibérée sur un SSD commettrait un suicide commercial.
C'est le genre de truc qui se terminerait avec un PR disaster, une classe action monumentale aux US, un sabordage en règle en entreprise, etc. La c'est juste un bug, move on. Y a un fix, il est dispo, il est annoncé et je pense que si tu appelles monsieur crucial au 0805 en haut à droite de leur site, ils savent te rediriger vers le patch.
En outre, c'est à l'attaquant d'apporter la preuve de ce qu'il avance. Ce journal ne participe qu'à une seule chose, que l'on reproche à l'ogre de Redmond : du FUD.
C'est pas parce que l'obsolescence programmée est un sujet à la mode qu'il faut essayer de le coller à toutes les sauces. C'est pas pour autant que Crucial n'a pas deux/trois améliorations à son process de QA à mettre en place…
# v4
Posté par Elwood_Blues . Évalué à 1.
Perso, j'ai acheté 2 V4 dans des machines Windows 7. Au bout de 6 mois, les 2 sont morts…
Par contre j'ai un M4 depuis 1 ou 2 ans et tout va bien pour lui.
# moi aussi j'hallucine
Posté par maboiteaspam . Évalué à -4.
Même après avoir parcouru les commentaires je trouve cela trop gros pour ne pas être instrumentaliser à un certain niveau.
Du coup bah : soutient et courage !
# Explication technique.
Posté par Lapinot (site web personnel) . Évalué à 4.
5184 h, 1 bug.
(5+1+8)*(4-1)=cqfd.
[^] # Re: Explication technique.
Posté par Toto . Évalué à 10.
Tu es sur que ce n'est pas plutôt INT(123,456789 * 42) - 1 ?
[^] # Re: Explication technique.
Posté par Gui13 (site web personnel) . Évalué à 2.
Celui là il déchire tout… Bien trouvé!
# 5184
Posté par Marotte ⛧ . Évalué à 3.
Non ça ça fait 1728.
5184 c'est 34 × 26
[^] # Re: 5184
Posté par fabien . Évalué à 3.
je doute que l'utiné interne soit l'heure en fait.
5184 heures fait 18 662 400 secondes.
on communique surle bug des 5184 c'est sans doute parce que c'est plus simple.
ensuite 18662400=43202
[^] # Re: 5184
Posté par Toto . Évalué à 1.
Tu veux dire que si on prends le temps en seconde, on retrouve encore plus de référence à 42 ?
5184 = round( ((42 * 2 +1) * 42² * 123,456789)/3600 + 42 )
Sinon, du coup, je ne vois quand même pas le 4320, même si c'est une puissance de deux, je ne vois pas ou peut etre l'overflow, sauf a stocker ça dans un type de donnée étrange
# Hum.... Non
Posté par Skydevil . Évalué à 2.
Je n'ai pas lu tous les commentaires (je passe en coup de vent sur DLFP), mais une mise à jour du firmware corrige ce bug. Il s'agit simplement d'un bug qui a été corrigé.
[^] # Re: Hum.... Non
Posté par SlowBrain (site web personnel) . Évalué à 2.
Tu as du passer très rapidement, vu qu'il en parle déjà dans son article, et que un bon tiers des commentaires parlent de ce correctif.
# Allons-y gaiement, déboguons de l'embedded !
Posté par serianox . Évalué à 2.
Certainement quelqu'un qui n'a jamais entendu parler d'endianness.
Et quand on s'amuse à déboguer, ne pas confondre la cause et la conséquence. Le compteur d'heures n'est qu'une représentation pour l'humain qui est très vraisemblablement fortement décorrélé de l'origine de la panne pour la machine.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.