Journal SSD Samsung 840: le fiasco annoncé du TLC ?

Posté par  . Licence CC By‑SA.
Étiquettes :
30
6
oct.
2014

Pour ceux qui ne seraient pas informés ou qui n'auraient pas constaté le problème sur leur propre modèle,
tous les SSD Samsung à base de TLC (840/840 EVO) ont un gros pépin: La vitesse de lecture s'écroule sur les zones de flash qui ne sont pas accédées depuis plusieurs semaines.

Sujet sur Overclock.net

Personnellement, la lecture brut d'un volume rarement accédé donne des sueurs.

cat /dev/mapper/SSDVol-foobar | pv > /dev/null

-> 2,29MiB/s

Apparemment la mémoire TLC était très bien dans les tests lors de la conception et de Wear Leveling, donc en écriture soutenue, mais personne ne s'était aperçu que les cellules ne répondaient plus correctement si elle n'étaient pas écrites régulièrement.

Actuellement, la réponse du support Samsung à ce problème est (je vous laisse constater l'arnaque):
- De reformater le disque complètement avec l'outil Samsung secure-erase.
- Si ça ne corrige pas le problème de retourner le disque.

Vive les sauvegardes… tant que rsync ne fait pas de checksum sur le fichier :/

  • # 840 Pro

    Posté par  . Évalué à 2.

    Apparemment le modèle 840 Pro (que je possède) n'est pas impacté (ouf !).
    Le lien que tu donnes parle d'un correctif à venir.

    • [^] # Re: 840 Pro

      Posté par  . Évalué à 5.

      Normal, le pro c'est du MLC, d'où aussi la différence de prix.
      C'est à parier que le "correctif" ne sera qu'une réécriture régulière des blocs.

      • [^] # Re: 840 Pro

        Posté par  (site web personnel) . Évalué à 6.

        C'est à parier que le "correctif" ne sera qu'une réécriture régulière des blocs.

        Et donc une usure prématurée ?

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: 840 Pro

          Posté par  . Évalué à 3.

          Oui. Mais bon, s'il faut une écrire par heure, par jour ou une par mois, l'impact sur la durée de vie sera différent.

      • [^] # Re: 840 Pro

        Posté par  (Mastodon) . Évalué à 3.

        Il y aura vraisemblablement de ça, mais peut-être aussi des tensions différentes qui pourraient permettre de maintenir les niveaux de détection acceptables.

        En tous cas moi qui ait lu hier soir le dossier SSD de CanardPC Hardware, je suis content de comprendre ce qu'il se passe :)

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Argh

    Posté par  . Évalué à 4.

    Génial je viens d acheter, recevoir et installer le mien… Du coup je me demande si je vais pas le renvoyer pendant la période de rétractation…
    Pourtant toutes les critiques étaient dithyrambiques !

    • [^] # Re: Argh

      Posté par  . Évalué à 4.

      Les critiques étaient dithyrambiques parce que pour se rendre compte du souci il fallait utiliser le SSD durant plusieurs mois ! Ce que ne font pas les testeurs des sites. Ça a par contre été mon cas, et je ne comprenais pas pourquoi il me paraissait beaucoup plus lent qu'au début (en fait aussi lent que le 5400 t/min qu'il était censé remplacer).
      Bref, je viens de changer de laptop, le nouveau a un SSD Toshiba qui court plus vite que son ombre: je suis aux anges :-)

      • [^] # Re: Argh

        Posté par  (Mastodon) . Évalué à 10.

        le nouveau a un SSD Toshiba qui court plus vite que son ombre

        Pour l'instant.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Argh

        Posté par  . Évalué à 1.

        Mais donc faut il le faire changer ? Je viens moi aussi de l'acheter et peut donc me rétracter …
        Reste à savoir si ça vaut le coup !

        • [^] # Re: Argh

          Posté par  . Évalué à 3. Dernière modification le 06 octobre 2014 à 21:39.

          Je me tâte aussi…
          En tout cas Samsung c'est terminé pour moi. 4 produits achetés ces dernières années et les 4 ont eu des problèmes : écran PC (alim cramée, j'ai dû prendre mon fer à souder…), smartphone (écran), maintenant le SSD et j'ai même eu le sèche-linge ! =)

    • [^] # Re: Argh

      Posté par  . Évalué à 4. Dernière modification le 06 octobre 2014 à 18:48.

      Argh… Je l'ai et c'est la version à 1 To (j'avais pas la place pour HDD + SSD …) qui m'a coûté bonbon (400 €).

      Et y'a quelques jours il a commencé à faire du bruit jusqu'à ce que je fasse :
      sudo fstrim -v /

      (aucun problème à part ça : hyper rapide et tout)

      Mais à quoi sert discard dans mes options de montage alors ?!

      Heureusement y'a 3 ans de garantie…

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Argh

        Posté par  (Mastodon) . Évalué à 2.

        Heureusement y'a 3 ans de garantie… je ne pense pas qu'on te garantisse un débit. Si le défaut ne fait que atteindre le débit, ça risque d'être compliqué.

        Ensuite le plus gros espoir réside dans un firmware qui résolve le problème (en jouant sur les tensions de flashage/détection ils arriveront peut-être à résoudre ça).

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Argh

          Posté par  . Évalué à 2.

          Heureusement y'a 3 ans de garantie… je ne pense pas qu'on te garantisse un débit.

          Je pensais surtout à mes données…

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Argh

            Posté par  (Mastodon) . Évalué à 7.

            Alors là c'est pire ! Garanti ou pas, si le disque meurt, tu les retrouveras pas.

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: Argh

              Posté par  . Évalué à 0.

              Bon ben elle sert à rien la garantie, en gros…

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Argh

                Posté par  (Mastodon) . Évalué à 4.

                Si : si le disque est en panne (il ne marche plus du tout), on t'en redonne un. 3 ans c'est pas mal comme garantie.

                En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Argh

          Posté par  (site web personnel) . Évalué à 6.

          Si le défaut ne fait que atteindre le débit, ça risque d'être compliqué.

          C'est pourtant exactement un "vice caché", qui n'a rien à voir avec la garantie. Un vice caché est une information qui aurait fait que tu n'aurais jamais acheter le bien, si tu la connaissais au moment de l'achat.

          "La première sécurité est la liberté"

      • [^] # Re: Argh

        Posté par  (site web personnel) . Évalué à 7.

        Et y'a quelques jours il a commencé à faire du bruit jusqu'à ce que je fasse :

        Euh un SSD qui fait du bruit ? o_O

        C'est pas plutôt un SSHD (le nom commercial des HDD avec un SSD qui fait office de cache) ? Qui serait vraiment en train de crever pour le coup. Quoique en fait un SSD qui fait du bruit doit être méchamment plus en train de crever qu'un HDD qui fait du bruit…

        • [^] # Re: Argh

          Posté par  (site web personnel) . Évalué à 9.

          Ou bien plutôt que de se contenter de faire des remontées S.M.A.R.T, ils ont intégré un petit haut parleur dans leur SSD afin de reproduire le bruit d'un HDD qui agonise, et ainsi alerter l'utilisateur lambda ? :D

          alf.life

        • [^] # Re: Argh

          Posté par  . Évalué à 5.

          Non, c'est un SSD (840 EVO). Et oui, ça m'a très surpris aussi.

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Upgrade

    Posté par  . Évalué à 5.

    Actuellement, la réponse du support Samsung à ce problème est (je vous laisse constater l'arnaque):
    - De reformater le disque complètement avec l'outil Samsung secure-erase.
    - Si ça ne corrige pas le problème de retourner le disque.

    Non, ils ont annoncé qu'un correctif de firmware sera bientôt disponible.
    J'ai appris ce problème ici et il n'est pas mentionné que Samsung demande de formater ou renvoyer en SAV…
    Ce n'est pas une arnaque, c'est une techno relativement nouvelle et c'est normal d'essuyer des plâtres.

    • [^] # Re: Upgrade

      Posté par  . Évalué à 1.

      c'est normal d'essuyer des plâtres

      Comment dire… Samsung n'est pas un petit artisan au coin de la rue. C'est juste une énorme entreprise avec des dizaines (centaines ?) de personnes ayant bossé techniquement sur ce projet.
      Et pas un n'a eu l'idée de faire un test de vieillissement ? Ben tient.

      Ils étaient parfaitement au courant. Les décideurs/commerciaux/financiers/etc ont décidé de lancer le produit. En sachant qu'il faudra faire un peu de communication au cas où.
      Traduction : ils n'en ont rien à battre des clients. Seul l'argent à court terme compte.
      L'esprit d'une entreprise ne change pas du jour au lendemain. Et rarement dans le sens positif. Donc Samsung fait partie des fabricants que je vais éviter pour ce qui est un poil important (stockage et mémoire en ce qui me concerne).

      • [^] # Re: Upgrade

        Posté par  . Évalué à 10.

        Ca c'est du tirage par les cheveux a mon avis…

        Des boites ayant pris des decisions stupides ou ayant oublie de faire qqe chose avant de lancer le produit, il y en a des rayons.

        Dire qu'ils se sont rates, totalement oui, ca c'est sur. Dire qu'ils ont fait expres, c'est bcp plus dur a affirmer.

      • [^] # Re: Upgrade

        Posté par  . Évalué à 10.

        généralement les teste de vieillissement se résume à utiliser le disque dans des conditions permettant d'accélérer le vieillissement du disque, comme écriture H24, ou soumis a de forte température, pas à le mettre au placard 3 mois et regarder ce que ça donne.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Upgrade

      Posté par  (site web personnel) . Évalué à 4.

      Ce n'est pas une arnaque, c'est une techno relativement nouvelle et c'est normal d'essuyer des plâtres.

      On aurait tout de même pu espérer un peu plus de sérieux lors des tests de validation du constructeur. Mais bon la pression pour proposer des SSD super rapides et de moins en moins cher (3 bits par cellule) l'a emporté sur la recherche de fiabilité.
      Je suis bien content de m'être méfié de la technologie TLC et d'avoir opté pour le 840 PRO.

      • [^] # Re: Upgrade

        Posté par  . Évalué à 3.

        J'ai un 840 depuis plus de 1 an et je n'ai pas encore eu de souci avec.

      • [^] # Re: Upgrade

        Posté par  . Évalué à 3.

        Je suis bien content de m'être méfié de la technologie TLC et d'avoir opté pour le 840 PRO.

        Ce n'est ni la même gamme, ni le même prix…

  • # 15 octobre

    Posté par  . Évalué à 2.

    Samsung annonce que le nouveau micrologiciel sera disponible le 15 octobre (ils connaissent le problème depuis le mois de mai…).

    Aucune information à propos de la méthode utilisée pour corriger le problème. Le principal candidat est le wear-leveling à l'ancienne : on déplace de temps en temps les données, ce qui ne se fait plus depuis quelques temps semble-t-il (je ne suis pas spécialiste mais des personnes qui semblent informées indiquent que c'est une méthode qui n'a plus cours).

    Je ne saisi pas comment ils peuvent être en mesure d'indiquer que le correctif sera ok pour une date précise. Pas la veille, pas le lendemain. Ça sent la bonne communication d'entreprise.

    • [^] # Re: 15 octobre

      Posté par  . Évalué à 4.

      Ça peut simplement dire qu'il est déjà prêt et qu'il s'agit du temps pour le distribuer.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: 15 octobre

        Posté par  . Évalué à 1.

        20 jours pour mettre un binaire en ligne ? Samsung l'a annoncé le 25 octobre.

        • [^] # Re: 15 octobre

          Posté par  (site web personnel) . Évalué à 10.

          Oui, pourquoi pas.

          Dans mon entreprise, entre le moment où tu écris un correctif, et le moment où tu peux l'envoyer dans le monde, il y a 2 semaines de tests au minimum.

          Ici, vu que tu veux tester un truc qui ne se voit qu'après plusieurs semaines, c'est un peu normal.

        • [^] # Re: 15 octobre

          Posté par  (site web personnel) . Évalué à 3.

          C'est vrai que ce n'est qu'un firmware de ssd, c'est pas comme si c'était critique…

          • [^] # Re: 15 octobre

            Posté par  . Évalué à 4.

            s'ils déploient un correctif qui résulte de la perte des données sur 5% des disque, ils vont s'en prendre plein la gueule, de mon expérience, il vaut mieux un patch en retard qu'un patch qui aggrave les choses.

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: 15 octobre

              Posté par  . Évalué à 0.

              Le problème n'est pas qu'il soit en retard, mais qu'ils soient en mesure de savoir à l'avance au jour près quand le correctif sera disponible. C'est juste impossible.
              D'où ma conviction que cette date n'est que de la communication. Un truc vide de sens, et de résultat. Donc le patch sera de qualité totalement inconnue (alors qu'avec un patch de bonne qualité, c'est la date qui est inconnue).

              • [^] # Re: 15 octobre

                Posté par  . Évalué à 8.

                Pas d'accord du tout

                Typiquement, un correctif dans du soft c'est :
                1) 2-10% le codage
                2) 90-98% le test

                Le 1) est vraiment la partie qui est difficile a evaluer, le 2) c'est normalement une passe de test definie a l'avance en tres tres grande majorite (le seul changement est ce que tu ajoutes pour le correctif), tu sais combien de temps ca prend, etc…

                Bref, donner une date a l'avance avec une grosse chance que ce soit correct est qqe chose de tres banal, on faisait ca constamment chez MS. Des fois on se ratait et ca sortait en retard car la phase de test trouvait des bugs et faillait refaire la chose, mais le plus souvent on etait dans la marge.

              • [^] # Re: 15 octobre

                Posté par  . Évalué à 3.

                Comme tu le dis ils travaillent dessus depuis mai, pouvoir indiquer 2 semaines avant que le correctif sera dispo à une date donnée ça ne me semble pas complètement absurde.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Pas de problème

    Posté par  (Mastodon) . Évalué à -3.

    Si je lis correctement le souçis, à priori s'il suffit de lire les fichiers de temps en temps le problème ne se pose que pour les ânes qui ne font jamais de backup.

    Faites des backups. Problème réglé.

    • [^] # Re: Pas de problème

      Posté par  . Évalué à 3.

      J'avais ce problème et pourtant je fais des backups tous les jours…

      Peut-être que c'était parce que je ne faisais pas des backups des fichiers système par ex. (usr & co que je peux réinstaller n'importe quand avec la distrib')… Et peut-être que ça ramait quand il y avait un binaire qui n'avait pas été utilisé depuis des lustres ! (Je ne peux pas vérifier: je n'ai plus la machine sous la main).

      • [^] # Re: Pas de problème

        Posté par  (Mastodon) . Évalué à 1.

        J'avais ce problème et pourtant je fais des backups tous les jours…

        La question c'est à mon avis surtout si tu ne faisais que des incrémentaux ou que tu faisais quand même un full régulier de temps en temps.

    • [^] # Re: Pas de problème

      Posté par  . Évalué à 3.

      Si la solution de backup est un peu intelligente, elle ne relit pas l'intégralité de tous les fichiers à chaque fois. Surtout les fichiers qui ne changent pas ou quasiment jamais.

    • [^] # Re: Pas de problème

      Posté par  . Évalué à 5.

      Si je lis correctement le souçis, à priori s'il suffit de lire les fichiers de temps en temps

      Non, il faut réécrire les cellules régulièrement.
      On se demande où est l'âne, qui par ailleurs est une sympathique bestiole.

      • [^] # Re: Pas de problème

        Posté par  (Mastodon) . Évalué à 2.

        La description parle "d'accéder". Pour moi ça voulait dire lecture. La ça devient moche s'il faut tout réécrire.

  • # F2FS ?

    Posté par  . Évalué à -2.

    Ce serait intéressant de savoir quel filesystem ils utilisent.
    Est-ce qu'ils utilisent F2FS ? (F2FS est développé par Samsung pour le kernel Linux)

    Référence : F2FS

    • [^] # Re: F2FS ?

      Posté par  . Évalué à 1.

      On parle de problèmes matériels ici, le filesystem (une composante logicielle) n'a pas grand chose à voir. Les amateurs de coléoptères me signaleront que le problème ici évoqué concerne le firmware/micrologiciel, donc quelquechose pouvant être rattaché à du logiciel, mais je suis sur qu'ils admettront que ça n'a toujours pas grand chose à voir avec le filesystem.

      • [^] # Re: F2FS ?

        Posté par  . Évalué à 0. Dernière modification le 07 octobre 2014 à 13:47.

        Comme tu dis, on parle de firmware/micrologiciel. Donc il s'agit bien de logiciel.

        le filesystem (une composante logicielle) n'a pas grand chose à voir

        Et pourquoi pas le filesystem ? Pour de la flash le logiciel de gestion du filesystem est loin d'être trivial. Regarde le code d'UBI et d'UBIFS dans le kernel linux…

        • [^] # Re: F2FS ?

          Posté par  . Évalué à 10.

          Bon, on y va pour les coléoptères. Du logiciel, y'en a partout, même dans ton CPU Intel, il y a du microcode, c'est à dire du logiciel. Reste qu'à un moment, il faut bien tracer des limites entre les composants "matériels" et "logiciels" d'un ordinateur.

          Même si ton CPU contient du logiciel (le microcode), tu seras d'accord pour admettre qu'il est complètement distinct du code de l'OS. Je peux changer d'OS (par exemple passer de Linux à FreeBSD), sans toucher au microcode de mon CPU. Je peux même même coder un OS sans avoir conscience du fait que le CPU utilise du microcode, parce que les OS utilisent une interface, en l'occurence l'ISA x86 dans le cas des CPU Intel, avec le CPU. On utilise généralement cette interface pour tracer la limite entre le logiciel et le matériel. Ce qui implémente l'interface, ici l'ISA x86 (le CPU) c'est du matériel, et ce qui utilise l'interface (l'OS), c'est du logiciel.

          Pour revenir aux cas des mémoires flash et SSD, tu mélanges tout, vraiment tout. Un SSD, d'un point de vue interface, ce n'est pas de la mémoire flash. Un SSD, ça répond à des commandes SATA (qui constituent son interface), comme un disque dur classique. Et quand une commande SATA te demande de stocker un cluster, t'es censé le stocker de manière à peu près fiable (c'est à dire pas sous une forme qui disparaisse en deux semaines). Pour reprendre les concepts du paragraphe précédent, l'interface entre matériel (le SSD) et le logiciel (le filesystem), c'est les commandes SATA. Les filesystem classiques (ext2-3-4, xfs etc.) utilisent les commandes SATA, et le SSD implémente les commandes SATA. Donc dans le cas d'un SSD, tout ce qui est "gestion de la flash" (wear-leveling, gestion des cellules de mémoire) c'est implémenté en matériel. Parler du filesystem d'un SSD, ça ne veut rien dire, parce qu'on peut utiliser n'importe quel filesystem sur un SSD. C'est un peu comme parler de l'OS d'un processeur, ça n'a pas de sens.

          Pour ne rien simplifier, il existe d'autres périphériques de stockages basés sur de la mémoire flash que les SSD, les MTD. l'interface entre matériel (la MTD) et le logiciel (le filesystem), ce n'est pas les commandes SATA. Ils implémentent une interface plus bas niveau pour le logiciel, ils exposent quasiment directement leurs cellules mémoires. C'est au logiciel, donc au filesystem d'effectuer la "gestion de la flash" (wear-leveling, gestion des cellules de mémoire). Des filesystem spécifiques ont étés développés pour les MTD : jffs2, ubifs, yaffs etc. On ne peut pas les utiliser sur un disque dur ni sur un SSD, parce qu'ils n'utilisent pas l'interface SATA mais une interface plus bas niveau spécifique aux MTD.

          Pour encore plus complexifier, l'interface SATA (donc celle dont je parle deux paragraphes plus haut) a été un peu modifiée pour répondre aux besoins spécifiques des SSD (ben oui, c'est pas exactement la même chose qu'un disque dur même si on a pas eu envie de changer d'interface), c'est notamment le cas de la commande TRIM. F2FS est un filesystem utilisant l'interface SATA ainsi que les extensions pour les SSD (notamment TRIM). Il essaye aussi d'utiliser l'interface SATA de manière "accomodante" pour un SSD. Mais ça reste un filesystem utilisant l'interface SATA, donc pas pour les MTD.

          Tout ça étant dit, je ré-insiste sur ma conclusion, parler du système de fichiers d'un SSD, ça n'a pas de sens ni même de "le logiciel de gestion du filesystem". Et ici, on parle bien d'un problème matériel, c'est bien au SSD de s'arranger pour qu'un cluster stocké ne soit pas perdu (un SSD n'est pas une MTD).

          • [^] # Re: F2FS ?

            Posté par  . Évalué à 0.

            Tu fais bien de mettre les points sur les i, parce que je me suis mal exprimé.

            Appuyons la discussion sur un petit schéma des flash translation layers :

            schéma

            Le correctif de firmware proposé par Samsung porte probablement sur les couches STL, BML et LLD.

            Ce que je voulais dire c'est que peut-être que les couches STL, BML et LLD dans les disques SSD de Samsung utilisent les mêmes algorithmes et la même dispositions sur les cellules mémoires qu'un filesystem existant : F2FS, UBIFS, JFFS2, etc.

            En reprenant les mêmes algorithmes et la même disposition sur le support physique, ils peuvent réutiliser du code open-source existant, et bénéficier de la robustesse de ce code et des algorithmes associés. Mais également à l'opposé, s'ils utilisent du code open-source existant et qu'ils ont le bug exposé dans le journal, c'est intéressant de le savoir, car le code open-source pourrait être infecté du même bug.

            • [^] # Re: F2FS ?

              Posté par  . Évalué à 4.

              s'ils utilisent du code open-source existant et qu'ils ont le bug exposé dans le journal, c'est intéressant de le savoir, car le code open-source pourrait être infecté du même bug

              Oui bon ok, on a compris depuis longtemps : tu n'as strictement rien compris à l'origine du problème, pas la peine d'insister.

              • [^] # Re: F2FS ?

                Posté par  . Évalué à 4.

                T'es dur, si il avait dit juste "UBI", il aurait levé une interrogation presque légitime.
                En fait pas vraiment parce que ce code est tellement lié à la technologie sous-jacente et précieux en terme d'innovation pour les constructeurs, qu'ils n'iraient pas se frotter à de la licence libre.

    • [^] # Re: F2FS ?

      Posté par  . Évalué à 3.

      Ils ne peuvent pas utiliser de filesystem (littéralement), car ils ne gèrent pas des fichiers. Le disque ne voit passer que des ordres liés à tel ou tel bloc du disque.

      Après, il me semble que le système de gestion des blocs sur un SSD fait partie des différences importantes entre fabricants, et ce qui leur permet d'avoir des performances plus ou moins bonnes. Il serait donc étonnant que celui de Samsung soit libre.

  • # Et dire que Toshiba prévoit la fin du HDD en 2025

    Posté par  . Évalué à 2.

    Selon cet article, sur Silicon.fr, "Toshiba estime que le prix des SSD au bit rejoindra celui des disques durs en 2025. Une tendance qui accélérerait leur disparition dès 2015."

    Quand on voit que la sauvegarde sur bande résiste pas trop mal, on se dit quand même que le bon vieux disque dur n'est pas prêt de mourir.

Suivre le flux des commentaires

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