SSD Samsung 850 Pro : V-NAND, plus de 500 Mo/s et une garantie de 10 ans

SSD Samsung 850 Pro : V-NAND, plus de 500 Mo/s et une garantie de 10 ans

Samsung empile les couches

Avatar de l'auteur
Sébastien Gavois

Publié dans

Sciences et espace

02/07/2014 3 minutes
46

SSD Samsung 850 Pro : V-NAND, plus de 500 Mo/s et une garantie de 10 ans

Samsung a officiellement annoncé ces SSD 850 Pro qui ont la particularité d'exploiter des puces de V-NAND, ou Vertical NAND, avec une structure en 3D. Remplaçants des 840 Pro, ils sont annoncés avec des performances de haut vol et une garantie pouvant atteindre 10 ans.

3D V-NAND

 

Il y a quasiment un an, Samsung présentait officiellement sa V-NAND, ou Vertical NAND. Il s'agit évidemment toujours de puces de mémoire Flash, mais avec une architecture empilant plusieurs couches (voir cette actualité pour tous les détails). C'est d'ailleurs pour cela qu'on parle parfois de 3D. Il était alors question de 24 couches superposées et du début de la production de masse.

850 Pro : les premiers SSD avec de la V-NAND sur 32 couches 

Après plusieurs mois d'attente, Samsung annonce donc le premier SSD exploitant des V-NAND : le 850 Pro avec des capacités allant de de 128 Go à 1 To. Entre temps, la technologie a évolué puisqu'on passe de 24 à 32 couches pour les puces de Flash V-NAND. Les avantages restent néanmoins les mêmes et Samsung met en avant les points suivants : plus de capacité pour une surface équivalente (par rapport à de la NAND classique), plus de performances, plus d'endurance et une consommation en baisse.

 

Du côté des performances, Samsung annonce 550 Mo/s en lecture, que ce soit pour le SSD de 128 Go ou celui de 1 To. En écriture, la situation est différente puisqu'il est question de 470 Mo/s pour le 850 Pro de 128 Go, ce qui est une belle performance pour cette capacité, et de 520 Mo/s pour les autres. Du côté des IOPS sur des fichiers aléatoires de 4 ko, on a 100 000 en lecture et 90 000 en écriture. La mémoire cache varie de 256 Mo à 1024 Mo suivant les modèles.

 

Samsung 850 Pro

Une garantie de 10 ans, mais dans la limite de 150 To

Côté endurance maintenant, Samsung annonce 150 To, quelle que soit la capacité. À titre de comparaison, les SSD 730 Series d'Intel sont annoncés pour 70 Go par jour pendant cinq ans (contre 20 Go en moyenne pour un SSD traditionnel), ce qui nous donne environ 125 To. Comme les SanDisk Extreme Pro, les SSD 850 Pro sont garantis pendant 10 ans, ou 150 To au premier des deux termes échus. Cela nous donne tout de même une moyenne d'environ 42 Go par jour pendant 10 ans.

 

Samsung annonce que ses nouveaux SSD de 128, 256, 512 Go et 1 To seront disponibles à partir du 21 juillet, pour 129,99, 199,99, 399,99 et 699,99 dollars respectivement, soit un tarif au Go compris entre 1,02 et 0,68 dollar tout de même. Les Extreme Pro se trouvent pour leur part à partir de 158,99308,99 et 515,99 euros pour respectivement 240,480 et 960 Go. On peut néanmoins espérer voir le prix des SSD V-NAND baisser lorsque la technologie sera parfaitement rodée et que la production augmentera significativement.

 

Voici une vidéo de présentation de la V-NAND de Samsung :

 

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

850 Pro : les premiers SSD avec de la V-NAND sur 32 couches 

Une garantie de 10 ans, mais dans la limite de 150 To

Fermer

Commentaires (46)


Dommage, je venais d’acheter mon 840 EVO 120 il y a à peine un mois… <img data-src=" />


200€ le 256 ? Intéressant, c’est le prix des 840 Pro.








IhazHedont a écrit :



200€ le 256 ? Intéressant, c’est le prix des 840 Pro.





Mouais, effectivement comme mentionné dans l’article c’est pas vraiment des prix révolutionnaires non plus… On va attendre les soldes <img data-src=" />



Ils en annoncent pas en mSATA dommage <img data-src=" />



Pour mon laptopt c’est bien pratique pourtant, je trouve dommage que cela ne se généralise pas d’avoir un slot HDD 2.5” et un mSATA en rab.








Avygeil a écrit :



Ils en annoncent pas en mSATA dommage <img data-src=" />



Pour mon laptopt c’est bien pratique pourtant, je trouve dommage que cela ne se généralise pas d’avoir un slot HDD 2.5” et un mSATA en rab.





Faut prendre un gros machin avec 2 emplacements 2.5” <img data-src=" />









Harbinger76 a écrit :



Dommage, je venais d’acheter mon 840 EVO 120 il y a à peine un mois… <img data-src=" />





Eeeeeeet oui c’est toujours comme ça l’informatique… ça va tellement vite que de toute façon on se dit forcément au bout d’un ou deux mois : “ooow sht”.



Ohhhhh 1 To <img data-src=" />








nobugging a écrit :



Mouais, effectivement comme mentionné dans l’article c’est pas vraiment des prix révolutionnaires non plus… On va attendre les soldes <img data-src=" />







Attend pas, personne ne les solde =(

T’as que des références très moyennes qui sont soldées.



150 TBW de garantie pour le modèle 1TB, ca fait juste un facteur 150. Il y a peu on était plus proche d’un facteur 1000 sur un SLC correctement géré. Mais les die-shrinks (faisant passer le nb de cycles d’erase de 100k à quelques k) et le MLC ont fait le reste et on arrive a ce résultat assez pitoyable, au fond.



Par ailleurs, 1GB de cache, ca devient du délire. Bonjour l’ampleur de la casse potentielle en cas de perte d’alim. A reserver aux laptops sur batterie (les SSD gamme pro évitent en général tout usage de cache).



Autre aléa peu connu: Le minima garanti (JEDEC) de rétention des données hors alim est de 1 an.



Ca sert à quoi au juste un truc sur lequel on pourra écrire dans la limite de 150 fois sa capacité… et qui ne pourra servir de sauvegarde fiable pour ses photos de famille dont les données bougent peu?

<img data-src=" />








john san a écrit :



Ohhhhh 1 To <img data-src=" />







les SSD samsung en 1 To en MLC existent déjà, mais pas très connu



http://www.caseking.de/shop/catalog/HDD/SSD/ODD/Solid-State-Drives-SSD/SAMSUNG/S…::22896.html









yl a écrit :



150 TBW de garantie pour le modèle 1TB, ca fait juste un facteur 150. Il y a peu on était plus proche d’un facteur 1000 sur un SLC correctement géré. Mais les die-shrinks (faisant passer le nb de cycles d’erase de 100k à quelques k) et le MLC ont fait le reste et on arrive a ce résultat assez pitoyable, au fond.



Par ailleurs, 1GB de cache, ca devient du délire. Bonjour l’ampleur de la casse potentielle en cas de perte d’alim. A reserver aux laptops sur batterie (les SSD gamme pro évitent en général tout usage de cache).



Autre aléa peu connu: Le minima garanti (JEDEC) de rétention des données hors alim est de 1 an.



Ca sert à quoi au juste un truc sur lequel on pourra écrire dans la limite de 150 fois sa capacité… et qui ne pourra servir de sauvegarde fiable pour ses photos de famille dont les données bougent peu?

<img data-src=" />







<img data-src=" />





  • 150 To, c’est la limite d’écriture pour une prise en charge en garanti. mais sur un 840 Pro, tu peux écrire environ 600 To avant d’avoir des problèmes

  • un SSD n’est pas fiable selon toi? moins qu’un HDD?









jeje07 a écrit :



(…)




  • un SSD n’est pas fiable selon toi? moins qu’un HDD?







    De manière générale, un SSD est beaucoup plus fiable qu’un HDD.



    Cependant, quand un HDD tombe en panne, ya encore moyen de récupérer des données, sur un SSD c’est niet <img data-src=" />



    Cependant je trouve aussi le commentaire de yl un peu incisif.









Avygeil a écrit :



De manière générale, un SSD est beaucoup plus fiable qu’un HDD.



Cependant, quand un HDD tombe en panne, ya encore moyen de récupérer des données, sur un SSD c’est niet <img data-src=" />



Cependant je trouve aussi le commentaire de yl un peu incisif.







de toutes facons, SSD ou HDD, il faut TOUJOURS faire des sauvegardes.



J’ai vu sur anandtech que samsung dispose d’un 850Pro de 128GB avec 8000TB d’écriture dessus et toujours fonctionnel (plus de 60000 cycles quand même), l’info viens de samsung donc elle vaut ce qu’elle vaut mais ça donne un ordre d’idée sur la fiabilité de la nand 3D <img data-src=" />



Après je pense que la garantie est à 150TB pour des raisons de gammes, les mêmes ssd avec 2 ou 3 condo en plus pour la gestion des coupures de courant seront surement vendu 2* plus chère aux pro avec une garantie d’écriture bien supérieure <img data-src=" />




Après plusieurs mois d’attente, Samsung annonce donc le premier SSD exploitant des V-NAND : le 850 Pro avec des capacités allant de de 128 Go à 1 To. Entre temps, la technologie a évolué puisqu’on passe de 24 à 32 couches pour les puces de Flash V-NAND. Les avantages restent néanmoins les mêmes et Samsung met en avant les points suivants : plus de capacité pour une surface équivalente (par rapport à de la NAND classique), plus de performances, plus d’endurance et une consommation en baisse.





Attention aux faux-semblants: Il faut préciser que ce n’est pas l’architecture de la puce qui la rend plus fiable et endurante, mais le retour à une finesse de gravure maitrisée de 40nm








Harbinger76 a écrit :



Dommage, je venais d’acheter mon 840 EVO 120 il y a à peine un mois… <img data-src=" />





entre PRO et EVO c’est pas du tout la même gamme de prix









yl a écrit :



150 TBW de garantie pour le modèle 1TB, ca fait juste un facteur 150. Il y a peu on était plus proche d’un facteur 1000 sur un SLC correctement géré. Mais les die-shrinks (faisant passer le nb de cycles d’erase de 100k à quelques k) et le MLC ont fait le reste et on arrive a ce résultat assez pitoyable, au fond.





tu confonds garantie contractuelle et endurance de la mémoire. La V-NAND de ce SSD est plus endurante que la MLC.



D’ailleurs les SSD MLC de la concurrence sont encore moins garantis (70TBW chez crucial par exemple)







raoudoudou a écrit :



Attention aux faux-semblants: Il faut préciser que ce n’est pas l’architecture de la puce qui la rend plus fiable et endurante, mais le retour à une finesse de gravure maitrisée de 40nm





C’est un peu lié quand même car c’est l’architecture V-NAND qui rend possible et rentable ce retour en arrière.









yl a écrit :



Par ailleurs, 1GB de cache, ca devient du délire. Bonjour l’ampleur de la casse potentielle en cas de perte d’alim. A reserver aux laptops sur batterie (les SSD gamme pro évitent en général tout usage de cache).





Sans cache les données seraient encore en RAM et seraient perdues également.

car le flux c’est:

RAM -&gt; cache -&gt; SSD



Pour la consistance du système de fichier les OS insèrent ce qu’on appelle des barrières, c’est à dire que l’OS demande au disque d’écrire les données dans l’ordre réellement sur le disque et attends que cela soit vraiment fait.







yl a écrit :



Autre aléa peu connu: Le minima garanti (JEDEC) de rétention des données hors alim est de 1 an.



Ca sert à quoi au juste un truc sur lequel on pourra écrire dans la limite de 150 fois sa capacité… et qui ne pourra servir de sauvegarde fiable pour ses photos de famille dont les données bougent peu?

<img data-src=" />





les 1 ans c’est pour les cellules qui usées et proches de leur fin de vie (3000 écritures).

Ensuite quand le SSD est alimenté les contrôleurs scannent régulièrement le ssd à la recherche de cellules à rafraîchir.

Enfin utiliser un SSD pour du stockage off-line c’est quand même encore super rare et overkill vu le prix.



Donc pour que sa pose problème il faut:




  • utiliser un SSD pour du backup off-line (très rare)

  • fatiguer le disque au point d’écrire plusieurs centaines de TB (très très très rare pour un disque de backup)

  • ne pas l’alimenter pendant 1 ans (peu fréquent)



    donc ton argumentaire est tellement pessimiste que j’en déduis que tu bosse pour un fabriquant de disque durs.



Les SSD deviennent de plus en plus INteressant. <img data-src=" />

Bon, je viens d’acheter un DD de 1 To pour 40€…. Mais pour de la sauvegarde.

Pour le système, le ssd devient INcontournable.








sylvere a écrit :



donc ton argumentaire est tellement pessimiste que j’en déduis que tu bosse pour un fabriquant de disque durs.







Non, juste eu à examiner qq cas de corruption car, comme tu le dis, les controleurs intègrent pas mal d’intelligence pour gérer un média flash nand par nature non fiable. Mais là ou il a de l’intelligence, il y a aussi fatalement de la connerie!

<img data-src=" />









jeje07 a écrit :





  • un SSD n’est pas fiable selon toi? moins qu’un HDD?







    Selon ce que tu en fais, oui, ca peut en effet être le cas. Quand on creuse un peu, pour y foutre un OS réinstallable à l’envie OK (en évitant d’y coller les logs/swap qui vont le fusiller). Tes photos de famille (même si les tarifs actuels limitent encore), je serais moins affirmatif!









Avygeil a écrit :



Cependant je trouve aussi le commentaire de yl un peu incisif.





Uniquement parce que tu les vois encore, une fois filtrés ils sont parfait. <img data-src=" />









yl a écrit :



Selon ce que tu en fais, oui, ca peut en effet être le cas. Quand on creuse un peu, pour y foutre un OS réinstallable à l’envie OK (en évitant d’y coller les logs/swap qui vont le fusiller). Tes photos de famille (même si les tarifs actuels limitent encore), je serais moins affirmatif!







ah bon le swap fusille un SSD? <img data-src=" />



Tu es au courant que le plus bas de gamme des SSD peut encaisser 200 To minimum sans problème? et perso je suis sur la base de 10 To par an (ce qui est assez énorme) avec le swap et tous les fichiers TEMP and co sur le SSD, ce qui représente dèjà 20 ans……

donc non le SWAP sur SSD ne pose aucun problème



Aucun souci avec un 840 pro 256 depuis presque 1 an pour l’OS. Silencieux et rapide. <img data-src=" />

Ce 850 512 me fait de l’oeil <img data-src=" />


La même en M.2 à 1,2 Go/s et j’achète.


Concernant la perte de données offline on parle de 6 mois a 1 an pour un SSD ( MLC NAND )

mais pour les HDD ?? (vu l’augmentation de la densité par plateau … )



quelqu’un aurait une info verifiée/verifiable ?








sylvere a écrit :



Pour la consistancecohérence du système de fichier les OS insèrent ce qu’on appelle des barrières, c’est à dire que l’OS demande au disque d’écrire les données dans l’ordre réellement sur le disque et attends que cela soit vraiment fait.





<img data-src=" />

Faux-ami en anglais :) .

Commentaire intéressant sinon.







yl a écrit :



les controleurs intègrent pas mal d’intelligence pour gérer un média flash nand par nature non fiable. Mais là ou il a de l’intelligence, il y a aussi fatalement de la connerie!

<img data-src=" />





<img data-src=" /> ta dernière phrase







yl a écrit :



Quand on creuse un peu, pour y foutre un OS réinstallable à l’envie OK (en évitant d’y coller les logs/swap qui vont le fusiller).





C’est drôle ce mythe des logs et du swap qui fusillent un SSD. J’ai mes logs et mon swap sur mon SSD depuis 2009 et il va très bien. Sauf à écrire des Go et des Go de logs par jour et de swaper comme un fou, il n’y aucune raison de ne pas s’en servir.







Abused a écrit :



Concernant la perte de données offline on parle de 6 mois a 1 an pour un SSD ( MLC NAND )

mais pour les HDD ?? (vu l’augmentation de la densité par plateau … )

quelqu’un aurait une info verifiée/verifiable ?





Ça m’intéresse aussi.









OlivierJ a écrit :



C’est drôle ce mythe des logs et du swap qui fusillent un SSD. J’ai mes logs et mon swap sur mon SSD depuis 2009 et il va très bien.







Le pb, c’est que depuis les finesses de gravures ont beaucoup évoluées. Alors la NAND de ton SSD de 2009 supportait minimum 100k cycles d’effacement quand actuellement ce serait probablement plus de l’ordre de 10k.



Fatalement, tu mets désormais beaucoup plus de pression sur le controleur, dont ses algos de wear leveling (et dans une moindre mesure, les raffraichissements périodiques de l’info stockée qui se perds sur la durée par fuite de charges), afin d’assurer la fiabilité.



Et si tu veux avoir les même durées de vie en terme de TBW avec un SSD actuel, il te faudra investir dans un SSD grosso modo 10 fois plus gros que ton modèle de 2009 tout en n’y mettant pas plus de données!



Tout ceci ne t’affranchissant pas des problèmes liés aux blocs que le firmware du contrôleur va (de plus en plus, avec les die-shrinks) bouger dans ton dos: Les LBA de ce qui bouge beaucoup (logs swaps) vont être remappés physiquement régulièrement vers d’autres emplacements libres (si le SSD est en début de vie et pas trop plein) ou qui bougent peu, générant alors des recopies de ces contenus. Et ce qui bouge peu intentionnellement, sur une machine, c’est surtout l’OS/soft… et qui bougera dans ton dos sur un SSD ce qui ne se produisait pas sur un HDD. Là, le bug du firmware ou la coupure d’alim au mauvais moment et c’est des emmerdes qui étaient autrefois envisageables.









jeje07 a écrit :



ah bon le swap fusille un SSD? <img data-src=" />







Vu que la moindre machine a désormais 4 à 8GB de DDR, c’est sans doute de moins en moins vrai. Mais ca n’a rien à voir avec le SSD: Le swap ne sert plus a rien, on peut dans la majorité des cas s’en passer en totalité si on ne fait pas de veille prolongée.



Quand à supporter 200TBW, c’est sans doute un peu optimiste pour des modèles actuels. Quand tu vois que Samsung en est à donner 150TBW pour un SSD de 1To, garantir de ne pouvoir ré-écrire en totalité un média que 150 fois je maintiens que c’est juste minable!



Si ca continues, dans 2 ans on en sera au niveau d’une galette réinscriptible. <img data-src=" />









sylvere a écrit :



Pour la consistance du système de fichier les OS insèrent ce qu’on appelle des barrières, c’est à dire que l’OS demande au disque d’écrire les données dans l’ordre réellement sur le disque et attends que cela soit vraiment fait.







Le pb étant que le SSD acquitte les blocs recus quand son contrôleur les as mis dans son propre cache (s’il en gère un)… pas quand ils sont physiquement écrits dans la NAND.



Et ca, toutes les précautions de l’OS n’y pourront jamais rien.



C’est pour cela que les SSD gamme pro désactivent le cache et compensent avec une l’organisation interne (parallélisme sur les NAND) pour assurer néanmoins des perfs correctes. Ils gèrent juste un buffer d’écriture, forcément nécessaire a cause de l’obligation d’effacer avant de ré-écrire propre à la flash, très limité en taille et assurent une veille d’alim pour bloquer toute nouvelle écriture quand elle est perdue combiné a des capacités permettant d’assurer la persistence de l’alim interne du SSD les quelques dixièmes de secondes nécessaire à assurer la fin des écritures en attente.



Avec 1GB de cache, c’est pas qq capas qui peuvent faire le job: C’est la batterie d’un laptop qui demeure le seul cas d’utilisation raisonnable d’un SSD ainsi spécifié. <img data-src=" />









yl a écrit :



Le pb, c’est que depuis les finesses de gravures ont beaucoup évoluées. Alors la NAND de ton SSD de 2009 supportait minimum 100k cycles d’effacement quand actuellement ce serait probablement plus de l’ordre de 10k.



Fatalement, tu mets désormais beaucoup plus de pression sur le controleur, dont ses algos de wear leveling (et dans une moindre mesure, les raffraichissements périodiques de l’info stockée qui se perds sur la durée par fuite de charges), afin d’assurer la fiabilité.



Et si tu veux avoir les même durées de vie en terme de TBW avec un SSD actuel, il te faudra investir dans un SSD grosso modo 10 fois plus gros que ton modèle de 2009 tout en n’y mettant pas plus de données!



Tout ceci ne t’affranchissant pas des problèmes liés aux blocs que le firmware du contrôleur va (de plus en plus, avec les die-shrinks) bouger dans ton dos: Les LBA de ce qui bouge beaucoup (logs swaps) vont être remappés physiquement régulièrement vers d’autres emplacements libres (si le SSD est en début de vie et pas trop plein) ou qui bougent peu, générant alors des recopies de ces contenus. Et ce qui bouge peu intentionnellement, sur une machine, c’est surtout l’OS/soft… et qui bougera dans ton dos sur un SSD ce qui ne se produisait pas sur un HDD. Là, le bug du firmware ou la coupure d’alim au mauvais moment et c’est des emmerdes qui étaient autrefois envisageables.







<img data-src=" />



faudrait arrêter la parano…..

des tests récents sur des SSD récents de 250 Go montrent qu’on peut écrire au minimum 200 To sur un SSD avant d’avoir des problèmes. Ensuite ils sont toujours utilisables, un 840 pro a tenu plus de 1000 To, la plupart des modèles claquent vers 700 - 900 to



http://www.hardware.fr/news/13780/endurance-ssd-point-1-petaoctet.html










yl a écrit :



Vu que la moindre machine a désormais 4 à 8GB de DDR, c’est sans doute de moins en moins vrai. Mais ca n’a rien à voir avec le SSD: Le swap ne sert plus a rien, on peut dans la majorité des cas s’en passer en totalité si on ne fait pas de veille prolongée.







c’est toi qui le dit…… Evite d’utiliser un logiciel comme paragon alignement tool sans swap parce que même avec 16 Go de RAM et 2 Go pour le swap, j’ai eu un message de mémoire insuffisante….. Après avoir monté le swap a 8 Go, plus de problème.

et avec le swap sur le SSD et en utilisation vraiment sans me priver (téléchargement sur SSD…), je suis sur la base de 10 To par an….. ca me quelques dizaines d’années sans problèmes avec un 840 pro…







yl a écrit :



Quand à supporter 200TBW, c’est sans doute un peu optimiste pour des modèles actuels. Quand tu vois que Samsung en est à donner 150TBW pour un SSD de 1To, garantir de ne pouvoir ré-écrire en totalité un média que 150 fois je maintiens que c’est juste minable!



Si ca continues, dans 2 ans on en sera au niveau d’une galette réinscriptible







voir message au dessus….

et encore une fois, 150 To, c’est la GARANTIE, pas la quantité de données inscriptibles….. dans le test dont j’ai mis le lien au dessus, le 840 pro 256 Go a tenu plus de 1000 To.










jeje07 a écrit :



faudrait arrêter la parano…..

des tests récents sur des SSD récents de 250 Go montrent qu’on peut écrire au minimum 200 To sur un SSD avant d’avoir des problèmes.







C’est sur que c’est déjà plus encourageant comme ratio… Mais au final le seul truc sur lequel tu peux raisonnablement compter c’est que que l’on te garantit. Et ca baisse pour les raisons évoquées.



Maintenant, ils n’ont pas non plus testé des coupures d’alim aléatoires dans les tests, histoire de voir comment ils apprécient! Le pire étant quand par malheur le firmware arrive à corrompre ses tables de pointeurs de blocs logiques/physiques. Là c’est le blocage pur et simple, tu ne récupères rien. Un HDD tu risquais certes un atterrissage forcé qui t’esquintais un cylindre, si la mécanique commencait à fatiguer et que le parcage des têtes commencait à peiner. Mais en général tu récupérais l’essentiel. Là c’est peau d’zob.



En prime, j’en ai laissé (des HDD) 2 ou 3 ans sans alim, aucun pb pour récupérer une image disque de sauvegarde le jour ou j’en avais besoin. Là, ils ont testé… 7j! Quelques semaines/mois, on aurait rigolé en SSD!









yl a écrit :



C’est sur que c’est déjà plus encourageant comme ratio… Mais au final le seul truc sur lequel tu peux raisonnablement compter c’est que que l’on te garantit. Et ca baisse pour les raisons évoquées.







Il n’y a aucune baisse sachant que pour les modèles précédents chez Samsung il n’y avait pas de limite d’écriture.

qui plus est, je ne sais pas si tu réalises que 150 To, c’est juste ENORME et pour 99% des gens ca représente bien 15 ans…..







yl a écrit :



Maintenant, ils n’ont pas non plus testé des coupures d’alim aléatoires dans les tests, histoire de voir comment ils apprécient!







la je suis d’accord!

après une coupure d’alim sur mon portable, mon m4 256 Go est mort…









jeje07 a écrit :



ah bon le swap fusille un SSD? <img data-src=" />

Tu es au courant que le plus bas de gamme des SSD peut encaisser 200 To minimum sans problème? et perso je suis sur la base de 10 To par an (ce qui est assez énorme) avec le swap et tous les fichiers TEMP and co sur le SSD, ce qui représente dèjà 20 ans……

donc non le SWAP sur SSD ne pose aucun problème











OlivierJ a écrit :



C’est drôle ce mythe des logs et du swap qui fusillent un SSD. J’ai mes logs et mon swap sur mon SSD depuis 2009 et il va très bien. Sauf à écrire des Go et des Go de logs par jour et de swaper comme un fou, il n’y aucune raison de ne pas s’en servir.





Si, ça peut poser problème, ce n’est pas un mythe. Tout simplement quand le swap est circoncis à une partition physiquement définie (ce qui est le cas sur toute installation propre). D’ailleurs il n’y a pas que le swap qui pose problème, les partitions système également de manière générale.

J’ai un ssd déjà en fin de vie (bon il date de 2012 aussi) pour ces raisons là : non pas qu’il soit complètement mort, mais les sections physiques correspondant à l’install Linux et l’install Windows sont HS pour de bon. La faute à des partitions réduites au minimum (35 Go pour Windows, 10 Go pour Linux) et la non-modification de certains comportements par défaut : indexation de fichiers windows, modification des dates d’accès sous linux, fichier de swap Windows sur la même partition &gt;&gt;&gt; peu de place pour répartir).



À côté de ça, son successeur a été correctement configuré : Windows 7 et plus XP, noatime dans le fstab Linux, définition du swapfile windows sur une grande partition, partitions système un peu plus larges de base, pas de partition de swap sous linux (8Go de mémoire vive), alignement des partitions sur les secteurs physiques…



Et du coup il a dépassé “l’ancienneté” de l’autre mais tourne toujours comme un charme. Bien sûr les progrès technologiques ont également joué (une génération d’écart je crois) ainsi que la marque.



Bref, le vrai (seul ?) risque pour le ssd, c’est l’usure concentrée d’une plage de secteurs physiquement délimitée (puisque du coup sauf erreur de ma part le wear-leveling du ssd ne peut agir puisque ça consiste à répartir les transactions sur l’intégralité du disque). À garder en tête en fonction des usages.



Évidemment celui qui fout juste un Windows 8 sur l’intégralité du ssd n’a aucune inquiétude à avoir (si ce n’est celle, fondamentale, d’utiliser un écosystème Windows pour jouer/travailler <img data-src=" />).



EDIT : Pour ceux que ça intéresse d’approfondir les questions d’optimisation de système, un lien pour Windows 7 et un pour la plupart des distribs Linux (à priori Windows 8 sait déjà optimiser son comportement pour les ssd).









yl a écrit :



En prime, j’en ai laissé (des HDD) 2 ou 3 ans sans alim, aucun pb pour récupérer une image disque de sauvegarde le jour ou j’en avais besoin. Là, ils ont testé… 7j! Quelques semaines/mois, on aurait rigolé en SSD!





Si je comprends bien, tu dis que les données sur ssd n’arrivent pas à persister au delà de quelques semaines ? Je ne comprends pas bien ce qui expliquerait ça ? Si tu as des infos/explications je suis preneur j’utilise un ssd comme stockage externe principal… :facepalm:









Citan666 a écrit :



Si, ça peut poser problème, ce n’est pas un mythe. Tout simplement quand le swap est circoncis à une partition physiquement définie (ce qui est le cas sur toute installation propre). D’ailleurs il n’y a pas que le swap qui pose problème, les partitions système également de manière générale.

J’ai un ssd déjà en fin de vie (bon il date de 2012 aussi) pour ces raisons là : non pas qu’il soit complètement mort, mais les sections physiques correspondant à l’install Linux et l’install Windows sont HS pour de bon. La faute à des partitions réduites au minimum (35 Go pour Windows, 10 Go pour Linux) et la non-modification de certains comportements par défaut : indexation de fichiers windows, modification des dates d’accès sous linux, fichier de swap Windows sur la même partition &gt;&gt;&gt; peu de place pour répartir).







j’ai du mal à comprendre comment tu peux avoir un SSD de 2012 qui soit mort…

ca veut dire quoi “les sections physiques correspondant à l’install Linux et l’install Windows sont HS pour de bon” ??? tu ne réécris par sur ces cellules, elles ne s’usent pas.

comprends pas….









jeje07 a écrit :



j’ai du mal à comprendre comment tu peux avoir un SSD de 2012 qui soit mort…

ca veut dire quoi “les sections physiques correspondant à l’install Linux et l’install Windows sont HS pour de bon” ??? tu ne réécris par sur ces cellules, elles ne s’usent pas.

comprends pas….





Je ne saurais pas t’expliquer exactement ce qui a provoqué l’usure prématurée, c’est trop technique pour moi-même.

Sous WIndows, ce qui a provoqué l’usure prématurée, pas de doute ce sont les BSOD régulièrement subis avec vérifications de disque obligées derrière + le swap de 4 Go sur une partition qui ne disposait que de 7 Go d’espace encore libre (je sous-estime toujours la gourmandise de Win).

Sous Linux, j’ai cru deviner à la lecture des articles sur l’optimisation des ssd que l’usure provenait des modifications de date d’accès sur les fichiers, qui si j’ai bien compris provoquaient dans la pratique une opération d’écriture (puisque tu modifies les métadonnées de l’inode correspondant). Plus le fait que j’éteignais et rallumais plusieurs fois par jour, plus un volume d’écriture système sans doute plus conséquent que l’utilisateur lambda (mumuse avec serveurs mail, web, machines virtuelles etc).



Peut-être qu’en fait c’est juste le ssd qui était moisi à la base, mais vu que là j’avais pris une bonne marque après m’être renseigné (le coup du Vertex qui claque en 2 mois m’ayant bien échaudé) je ne pense pas.

Enfin, une fois encore je ne suis pas technicien. Le constat que je fais me semble simplement le plus probablement vrai compte tenu des quelques connaissances acquises sur le sujet.



EDIT : Je m’aperçois que je n’avais pas répondu à ta question au final <img data-src=" />. Je voulais dire par cette phrase que physiquement les systèmes n’arrivent plus à lire le contenu des cellules du SSD. Ce qui dans les faits sous Windows se traduit par un BSOD dans les 3mn chrono.

Quant à Linux, quand tu lances un terminal pour faire quoi que ce soit un message d’erreur d’accès à des secteurs défile en boucle et les opérations d’écriture sur la partition système tendent à foirer. Note néanmoins que même alors, les applications que tu avais déjà lancé juste après le démarrage et l’environnement fonctionnent elles comme un charme (encore une illustration de la robustesse de Linux : en surface tout va bien <img data-src=" />).









Citan666 a écrit :



Si je comprends bien, tu dis que les données sur ssd n’arrivent pas à persister au delà de quelques semaines ?







Cf les spec JEDEC. Selon que c’es un modèle grand public ou pro, la durée varie. Pour les raisons, cf la structure microelectronique d’un bit de stockage flash (un transistor modifié, en gros, capable de stocker une charge… qui va fuir dans le temps).









yl a écrit :



Le pb, c’est que depuis les finesses de gravures ont beaucoup évoluées. Alors la NAND de ton SSD de 2009 supportait minimum 100k cycles d’effacement quand actuellement ce serait probablement plus de l’ordre de 10k.





Mon SSD est un MLC.

Je connais le principe de wear leveling (depuis avant les SSD), mais je ne comprends toujours pas pourquoi je ne devrais pas mettre mes logs ni mon swap (sur Linux je swappe peu d’ailleurs) sur mon SSD, c’est juste une question de volumétrie. C’est un disque hein, pas un truc fragile à ne pas utiliser.









jeje07 a écrit :



j’ai du mal à comprendre comment tu peux avoir un SSD de 2012 qui soit mort…

ca veut dire quoi “les sections physiques correspondant à l’install Linux et l’install Windows sont HS pour de bon” ??? tu ne réécris par sur ces cellules, elles ne s’usent pas.

comprends pas….







Si, car si ton système de fichiers utilises des blocs logiques (LBA) en adressage… ca ne correspond pas sur un SSD a des blocs physiques. Le controlleur, maintient une table de pointeurs de correspondance pour quand il bouge un bloc physique pour un LBA donné.



C’est obligatoire car une flash nécessite d’effacer (une flash effacée a tous ses bits à 1) avant de ré-écrire (passer les bits qui doivent l’être à zéro) =&gt; une modif d’une donnée d’un LBA, c’est forcément un cycle de read-modify-write qui va réutiliser un autre bloc physique pré-effacé en tâche de fond.



Tu ajoutes le wear-levelling qui va, pour égaliser l’usure, bouger les blocs physiques correspondant aux LBA de ce qui change beaucoup et tu comprends que ce qui bouge peu (fichiers de l’OS/applicatif) va pouvoir se faire botter le cul par des LBA de log/swap ou data régulièrement. Sans aucune considération pour le partitionnement, le controlleur du SSD n’interprète pas la table de partition.









Citan666 a écrit :



Si, ça peut poser problème, ce n’est pas un mythe. Tout simplement quand le swap est circoncris à une partition physiquement définie





Le swap est circoncis, il est casher alors ? <img data-src=" />







Citan666 a écrit :



J’ai un ssd déjà en fin de vie (bon il date de 2012 aussi) pour ces raisons là : non pas qu’il soit complètement mort, mais les sections physiques correspondant à l’install Linux et l’install Windows sont HS pour de bon. La faute à des partitions réduites au minimum (35 Go pour Windows, 10 Go pour Linux)





Ton disque a vraiment un souci.

Encore une fois, même si un SSD n’a pas les mêmes capacités de stockage qu’un disque magnétique, ce n’est pas non plus une raison pour ne pas l’utiliser normalement.

Mes partitions Linux font 5 Go et le disque se porte très bien (un MLC de 80 Go de 2009).







Citan666 a écrit :



Sous Linux, j’ai cru deviner à la lecture des articles sur l’optimisation des ssd que l’usure provenait des modifications de date d’accès sur les fichiers, qui si j’ai bien compris provoquaient dans la pratique une opération d’écriture (puisque tu modifies les métadonnées de l’inode correspondant).





Ça fait des années que par défaut le noyau utilise l’option “relatime” qui évite la modification inutile de l’access time.









yl a écrit :



Si, car si ton système de fichiers utilises des blocs logiques (LBA) en adressage…





C’est le cas depuis des années.







yl a écrit :



Tu ajoutes le wear-levelling qui va, pour égaliser l’usure, bouger les blocs physiques correspondant aux LBA de ce qui change beaucoup et tu comprends que ce qui bouge peu (fichiers de l’OS/applicatif) va pouvoir se faire botter le cul par des LBA de log/swap ou data régulièrement.





Ce que tu décris, avec le cycle read-modify-write, s’appelle “write amplication” (amplification en écriture), et c’est le boulot d’un bon contrôleur de réduire cette amplification (les SandForce ont été innové sur le sujet à un moment).









OlivierJ a écrit :



Ce que tu décris, avec le cycle read-modify-write, s’appelle “write amplication” (amplification en écriture), et c’est le boulot d’un bon contrôleur de réduire cette amplification (les SandForce ont été innové sur le sujet à un moment).







La compression des données à la volée par exemple… mais reste qu’avoir en permanence des carreaux, que l’on espère parfaits, de ce qui bouge peu sur un SSD pour éviter que ce qui bouge beaucoup flingue trop vite les secteurs de flash correspondants est un problème nouveau. De même devoir rafraîchir les données régulièrement pour éviter leur perte dans le temps génère de l’écriture même quand tu n’en fais pas. Le SSD, c’est le truc qui s’use même si on ne s’en sert pas! Vu ainsi, c’est vrai qu’il vaut peut-être mieux s’en servir…



La fragilité n’est certes plus mécanique, elle est différente mais elle est là.



Par nature une NAND c’est pas fiable, ca tiens pas des années sans fonctionner, les niveaux pour trancher si on a stocké un 0 ou un 1 doivent en permanence être ré-étalonnés, le contrôleur fait en permanence un boulot, plus complexe et risqué qu’un HDD, derrière ton dos et qui a bien plus de chances de poser de gros pépins sur coupure d’alim brutale etc…



C’est comme tout, ca s’utilises a bon escient. Le pb étant que l’on vante une sécurité qui n’est pas forcément meilleure en SSD qu’en HDD pour tous les usages. En gros, il n’y a probablement que pour ceux qui baladent en permanence leur laptop en marche qu’elle sera inconditionnellement meilleure (si l’utilisateur n’a pas trop bidouillé les actions sur niveau de batterie critique)!









yl a écrit :



Par ailleurs, 1GB de cache, ca devient du délire. Bonjour l’ampleur de la casse potentielle en cas de perte d’alim. A reserver aux laptops sur batterie (les SSD gamme pro évitent en général tout usage de cache).





Salut,

sur cette remarque, 1Go de cache, c’est pas si gros si tu compares au débit du disque en fait… à 500Mo/s, ça fait juste 2s d’écriture… avec un bon condensateur, ça doit passer!



D’autre part, je ne pense pas que le système attende que le cache soit plein avant d’écrire. En revanche, ça doit servir lorsque le disque doit déplacer des données, réorganiser des trucs : il peut lire plein de choses, faire ses calculs, écrire, puis effacer les cellules sources après en une fois!