Crucial lance ses SSD MX500 (3D NAND TLC), le modèle 1 To vendu 265,19 euros

Crucial lance ses SSD MX500 (3D NAND TLC), le modèle 1 To vendu 265,19 euros

Par Sébastien Gavois

Le 20 Décembre 2017 à 09h18
Sciences et espace
1 min 13

Crucial lance ses SSD MX500 (3D NAND TLC), le modèle 1 To vendu 265,19 euros

Un an et demi après les MX300, le fabricant dévoile ses nouveaux SSD MX500. Ne cherchez pas les MX400, ils sont passés aux oubliettes.

Disponibles en version de 250 Go à 2 To, au format M.2 2280 (1 To maximum) ou S-ATA, ils proposent tous les mêmes débits : 560 Mo/s en lecture, 510 Mo/s en écriture (avec Dynamic Write Acceleration) pour respectivement 95 000 et 90 000 IOPS.

Dans le détail, un contrôleur Silicon Motion SM2258 est de la partie, avec des puces de 3D NAND TLC sur 64 couches (32 couches pour les MX300). Le fabricant annonce une endurance de 100 To pour la version de 250 Go, 180 To pour celle de 500 Go, 360 To pour 1 To et enfin 700 To pour le SSD de 2 To.

Dans tous les cas, la garantie est de cinq ans. Amazon propose d'ores et déjà le MX500 S-ATA de 1 To pour 265,19 euros.

Commentaires (13)


BlackYeLL Abonné
Le 20/12/2017 à 10h36

C’est quoi “l’endurance” ? 360 To pour 1 To, ça veut dire qu’on peut écrire sur la totalité du disque 360 fois ?


Vinzenz-o
Le 20/12/2017 à 11h26

C’est bien ça.



Sur le 1 To, il est possible d’écrire 360 To avant que les “cellules” ne deviennent potentiellement défaillantes (et donc risque potentiel de perte de données).



Mais il faut bien se dire que ça correspond à:





  •  1 To par jour pendant 1 an

  • 500 Go par jour pendant 2 ans

  • 250 Go par jour pendant 4 ans

  • 125 Go par jour pendant 8 ans

  • 62,5 Go par jour pendant 16 ans



    Bref, c’est assez large… Qui écrit vraiment “ne serait-ce que” 125 Go de données par jour, tous les jours de l’année, pendant 8 ans ? ;)

    Et d’ici 8 ans, on aura encore beaucoup avancé sur le stockage de masse.



    Et si on a vraiment besoin d’écrire autant de données quotidiennement, il vaut mieux se tourner vers d’autres solutions, comme des DD “normaux”.


Case_Of Abonné
Le 20/12/2017 à 11h30

Personnellement, je préfère les disques SLC aux disques TLC


OlivierJ Abonné
Le 20/12/2017 à 13h03

Oui, c’est la durée de vie garantie. C’est vrai que ça semble vraiment peu, 300 à 400 écritures complètes du disque, dans la fourchette basse de l’endurance d’une cellule TLC.



Après, l’endurance est en pratique souvent supérieure, du moins c’était le cas de plusieurs disques testés par un site américain il y a plus de 2 ans :http://linuxfr.org/users/voixoff/journaux/endurance-des-ssd .


OlivierJ Abonné
Le 20/12/2017 à 13h13







Vinzenz-o a écrit :



[…]Bref, c’est assez large… Qui écrit vraiment “ne serait-ce que” 125 Go de données par jour, tous les jours de l’année, pendant 8 ans ? ;)

Et d’ici 8 ans, on aura encore beaucoup avancé sur le stockage de masse.





<img data-src=" />







Vinzenz-o a écrit :



Et si on a vraiment besoin d’écrire autant de données quotidiennement, il vaut mieux se tourner vers d’autres solutions, comme des DD “normaux”.





Oui, ou vers un disque SSD disposant d’une meilleure endurance (ce qui se paie mais pas tellement plus cher), en TLC ou MLC.



Il faut savoir que les vendeurs de baies (NetApp, EMC, autres) sont passés presque exclusivement à des disques Flash, sans surcoût majeur ; certes, on parle de disques “pro” donc les magnétiques sont plus chers qu’en grand public, en comparaison, et les disques Flash sont plutôt des e-MLC.







Case_Of a écrit :



Personnellement, je préfère les disques SLC aux disques TLC





Je crois que ça a quasiment disparu du marché, les SLC.



Nozalys Abonné
Le 20/12/2017 à 13h53







Vinzenz-o a écrit :



Bref, c’est assez large… Qui écrit vraiment “ne serait-ce que” 125 Go de données par jour, tous les jours de l’année, pendant 8 ans ? ;)

Et d’ici 8 ans, on aura encore beaucoup avancé sur le stockage de masse.





C’est vrai, cependant le problème ne vient pas tant de la quantité de données mais de la bonne répartition de celles-cis.



De nombreux fichiers temporaires sont générés par l’O.S. et les applications, si par malchance c’est souvent la même zone du SSD qui est utilisée, ces cellules vieilliront plus rapidement que d’autres, pouvant entrainer des instabilités.



Quand bien même le contrôleur est sensé éviter cela, l’O.S. également, je ne suis pas certain du fonctionnement réel de ces fonctions de protections.



Je dis ça, je suis passé aux SSD depuis longtemps, le premier SSD que j’ai acheté en 2008 fonctionne toujours à merveille…. A côté de ça, je n’ai plus aucun HDD d’avant 2010 fonctionnel….



OlivierJ Abonné
Le 20/12/2017 à 14h33







Nozalys a écrit :



C’est vrai, cependant le problème ne vient pas tant de la quantité de données mais de la bonne répartition de celles-cis.

De nombreux fichiers temporaires sont générés par l’O.S. et les applications, si par malchance c’est souvent la même zone du SSD qui est utilisée, ces cellules vieilliront plus rapidement que d’autres, pouvant entrainer des instabilités.

Quand bien même le contrôleur est sensé éviter cela, l’O.S. également, je ne suis pas certain du fonctionnement réel de ces fonctions de protections.





Faudrait peut-être mettre à jour tes connaissances en terme de SSD. <img data-src=" />



La répartition des écritures (principe du wear leveling) marche particulièrement bien, il n’y a qu’à voir l’endurance réelle constatée lors des tests (cf un des liens que j’ai indiqués).



Nozalys Abonné
Le 20/12/2017 à 15h52

Je vais lire ça, merci.



Je me pose quand même la question du fonctionnement de ces algos et de la manière dont le SSD stocke l’information sur l’état de ses cellules qui doit coûter autant de bits de mémoire que de cellules… Et si ces bits sont eux-même corrompus.. ?



Je ne dis pas que c’est pas fiable, je constate le contraire, comme beaucoup de monde et de tests. Je me demande juste comment cela fonctionne en pratique.


Vinzenz-o
Le 20/12/2017 à 17h33

Je t’avoue qu’en pratique, je ne sais pas précisément comment fonctionne la répartition et si elle est vraiment efficace.

Je me borne à la théorie qui veut que ça fonctionne bien&nbsp;<img data-src=" />


OlivierJ Abonné
Le 21/12/2017 à 09h08







Nozalys a écrit :



Je me pose quand même la question du fonctionnement de ces algos et de la manière dont le SSD stocke l’information sur l’état de ses cellules qui doit coûter autant de bits de mémoire que de cellules… Et si ces bits sont eux-même corrompus.. ?



Je ne dis pas que c’est pas fiable, je constate le contraire, comme beaucoup de monde et de tests. Je me demande juste comment cela fonctionne en pratique.





Tu as raison de te demander comment ça fonctionne, ça doit être plus ou moins complexe c’est sûr, chaque fabricant ayant sa variante ; on peut le supposer du fait des modèles ces dernières années qui ont eu des bugs et qui devaient être “reflashés” (je parle du firmware).



Pour ton premier paragraphe, ce sont les premières questions que se sont posées les concepteurs, et les algorithmes en tiennent compte, et surtout les tests ont dû être très nombreux pour valider un fonctionnement plus ou moins optimal (ils ont dû griller un paquet de SSD en bêta-test chez tous les fabricants :-) , sans parler de certaines séries qui elles ont grillé chez les consommateurs, comme des OCZ il y a plusieurs années).



Nozalys Abonné
Le 21/12/2017 à 12h27

<img data-src=" />









Vinzenz-o a écrit :



Je t’avoue qu’en pratique, je ne sais pas précisément comment fonctionne la répartition et si elle est vraiment efficace.

Je me borne à la théorie qui veut que ça fonctionne bien <img data-src=" />





Moi aussi, mais pour aller + dans le détail, ce qui me paraît dingue en fait c’est la chose suivante : prennons un SSD TLC, ça veut dire qu’une cellule contient 3 bits. Pour pouvoir marquer une cellule en mauvaise santé et ne plus l’utiliser, il faut bien que le contrôleur puisse mémoriser sa position. Donc stocker au moins 1 bit quelque part. En partant de là, ça signifie que pour 3 bits de stockage utile il faut 1 bit de plus.



Du coup, sur un SSD de 500 Go, en fait il y a 665 Go de mémoire à l’intérieur du disque.. ? <img data-src=" />



Je suis convaincu que c’est pas comme ça que c’est fait, mais je ne vois pas comment faire autrement. <img data-src=" />



Bref, en tout cas ça fonctionne vachement bien, c’est genre 10 fois plus stable/pérenne qu’un HDD alors bon..



OlivierJ Abonné
Le 21/12/2017 à 12h36







Nozalys a écrit :



Moi aussi, mais pour aller + dans le détail, ce qui me paraît dingue en fait c’est la chose suivante : prennons un SSD TLC, ça veut dire qu’une cellule contient 3 bits. Pour pouvoir marquer une cellule en mauvaise santé et ne plus l’utiliser, il faut bien que le contrôleur puisse mémoriser sa position. Donc stocker au moins 1 bit quelque part. En partant de là, ça signifie que pour 3 bits de stockage utile il faut 1 bit de plus.



Du coup, sur un SSD de 500 Go, en fait il y a 665 Go de mémoire à l’intérieur du disque.. ? <img data-src=" />



Je suis convaincu que c’est pas comme ça que c’est fait, mais je ne vois pas comment faire autrement. <img data-src=" />





Je t’invite (bis) à regarder comment est conçue la mémoire Flash :-) .



En l’occurrence, ça ne marche pas par cellule mais par portions bien plus importantes, sachant que la granularité pour l’effacement est différente de pour la lecture, cfhttp://www.tomshardware.fr/articles/ssd-flash-disques,2-393-3.html par exemple.



Lecture sur une page, écriture sur un bloc



L’interface séquentielle oblige aussi à travailler avec la page comme unité minimale pour la lecture. Si on veut accéder à un bit précis, il faut charger entièrement une page. Cette particularité explique que la mémoire flash manque parfois d’efficacité avec les très petits fichiers : la lecture d’un fichier de la taille d’une page (généralement 4 ko) et d’un fichier plus petit prend le même temps.



Pour l’écriture, on travaille au niveau du bloc : la moindre écriture oblige à effacer entièrement le bloc de données avant d’écrire une nouvelle valeur. On a donc le même problème qu’en lecture, écrire 1 bit ou écrire 256 ko (taille typique d’un bloc) nécessite le même temps au final : on doit reprogrammer entièrement le bloc. En pratique, l’écriture de petits fichiers (sous les 256 ko) est donc assez lente avec de la mémoire flash.



Nozalys Abonné
Le 21/12/2017 à 12h48

Encore merci <img data-src=" />

Je savais pour l’écriture (lu dans l’article que tu as cité plus haut) mais pas pour la lecture. Donc au final, le marqueur de “cellule morte” porte sur un bloc entier, donc une perte de 256 ko à chaque fois. Ok, le ratio bits utiles/bits de contrôle n’est clairement plus du même ordre alors. <img data-src=" />



Merci pour ce partage de connaissances en cette période de pré-fêtes <img data-src=" />


Fermer