Phison vient de dévoiler un SSD 2,5" avec une capacité de 15,36 To, un record selon le fabricant. QLC oblige, il ne brille par contre pas par ses performances ou son endurance, mais pourrait se démarquer grâce à son tarif.
« La première solution au monde de SSD d'entreprise de 15,36 To en QLC » est signée Phison, qui utilise ici son contrôleur S12DC. Selon le fabricant, c’est le « SSD SATA QLC [quatre bits par cellule, ndlr] de 2,5" (7 mm) de 15,36 To avec la capacité la plus élevée au monde ».
Des mots choisis avec soin, car il existe déjà depuis des années des SSD de 2,5" avec une capacité plus importante. En 2016, Samsung annonçait par exemple son PM1643 de 30,72 To. Mais il exploitait alors des puces de flash NAND TLC (trois bits par cellule) et mesurait 14,8 mm d’épaisseur, deux fois plus que le nouveau modèle de Phison.
Interface S-ATA et endurance de 0,1 DWPD seulement
Samsung exploitait également une interface SAS 3.0 à 12 Gb/s Dual Port pour des débits allant jusqu’à 2 Go/s en lecture et en écriture, Phison se contente du S-ATA 6 Gb/s, et donc de performances bien plus limitées.
Il annonce ainsi 530 Mo/s et 90 000 IOPS en lecture pour 220 Mo/s et 10 000 IOPS en écriture. L’endurance n’est pas spécialement élevée non plus avec 0,1 DWPD (Disk Write Per Day) là où le PM1643 fait dix fois mieux. Merci à QLC. Ce produit se destinera, comme tous ceux de son genre, surtout à des usages en lecture (notamment du cache).
Les premiers exemplaires du S12DC QLC SSD ont été envoyés en août. Phison propose ensuite à ses partenaires de personnaliser les périphériques de stockage à leur nom, avec leur logo. Il en est de même pour le firmware, avec éventuellement des fonctionnalités supplémentaires suivant les besoins.
La garantie est de cinq ans. L'ensemble des caractéristiques techniques se trouve par là.
Quid du tarif ?
Mais Phison ne donne pas le tarif et c’est bien dommage, car c’est surement sur ce point que le fabricant pourrait se démarquer. Il faudra donc attendre que les premiers modèles soient commercialisés pour le découvrir.
À titre de comparaison, le SSD PM1643 de 15,36 To de Samsung est vendu 4 500 euros environ, contre le double pour la version de 30,72 To. Pour le grand public, on trouve des SSD QLC S-ATA à partir de 900 euros pour 8 To.
Commentaires (58)
#1
Intéressant. Si on sait que QLC = lent, est-ce qu’on peut également dire que QLC = moins fiable dans le temps ?
#2
Bon on va attendre que les pris soit raisonnable pour un particulier.
#3
pour les particuliers 900€ ^^
faut être cinglé ou avoir un besoin ultra précis pour claquer 900€ pour 8to non ?
#4
“QLC oblige, il ne brille par contre pas par ses performances ou son endurance, mais pourrait se démarquer grâce à son tarif.”
0,1 DWPD c’est quand même très faible pour un disque “entreprise”
qu’est ce qui justifie une telle dénomination d’ailleurs ? son prix ?
#5
Le cache à 530Mo/s. Bof bof. Sans compter que pour gérer un cache de 15To, il faut combien de RAM pour se rappeler quoi est où?
Après, beaucoup de BDD sont légères en écriture; de nouveaux moteurs se profilent pour éviter de reconstruire des index et autre; les SSD en RAID pourront à terme permettre des BDD avec des perfs suffisante sans trop de RAM je pense, et sans risquer de pourrir le SSD avec des écritures indûes.
Mais pour le moment, des SSD QLC, je ne les mettrais pas trop dans un SAN…
#6
Ce n’est pas trop le genre de produit que tu mets seul dans un PC grand public ;)
#7
” Selon le fabricant, c’est le « SSD SATA QLC [quatre bits par cellule, ndlr] de 2,5” (7 mm) de 15,36 To avec la capacité la plus élevée au monde ». “
C’est assez particulier comme formulation. Il existerait donc d’autres SSD SATA QLC de 2.5” de 15.36 To, mais avec une capacité moins élevée?
A force de bullshit marketing, on finit par dire n’importe quoi…
#8
Donc le SSD de Phison est 2 fois moins épais que le Samsung pour… 2 fois moins d’espace de stockage… c’est donc la même densité, rien de quoi fanfaroner, si?
#9
Ce n’est pas comme cache mais pour les documents que je me servirais de ce genre de SSD.
#10
Par définition : QLC (4 bits sur une cellule) < TLC (3) < MLC (2) < SLC (1)
L’idée étant qu’une cellule sur une TLC sera donc sollicitée beaucoup plus que sur un MLC ou un SLC.
La plupart des SSD grand-public qu’on trouve aujourd’hui sont des TLC (voire des QLC qui commencent à arriver), les MLC sont rares et les SLC sont devenus quasiment introuvables (à part pour du matériel pro où ils doivent sûrement exister)
Mais bon, même si l’endurance est moins bonne dans le temps, tout est relatif.
Il me semble qu’une cellule TLC, c’est de l’ordre de 1000 écritures avant que ça commence à avoir des défauts (corrigez-moi si je me trompe). Du coup, si on a un SSD de 500 Go, on aura le temps d’écrire 500 To. Pour un particulier c’est large ^^
#11
Oui. À ce sujet, lire cet excellent article : https://www.ontrack.com/fr/blog/quelle-est-la-duree-de-vie-reelle-des-ssd/
Extrait choisi :
Et je citerais encore, en complément (Canard PC Hardware, n°42, octobre-novembre 2019, page 31) :
Bref, ne vous préoccupez pas tant de l’usure de vos SSD, mais effectuez des sauvegardes fonctionnelles et pérennes, c’est le plus important, toutes technologies de stockage confondues !
#12
Le marketing, comme d’hab.
#13
Si en SLC, c’est une charge stockée qui faisait la valeur 0/1 du bit avec un seul comparateur, sans doute vers une valeur médiane… en MLC la comparaison n’est alors plus tout ou rien: On compare des niveaux de charge qui correspondent à autant d’états binaires que de niveaux séparés possibles. Avec 3 niveaux de comparaison on est capable de discriminer 4 niveaux de charge correspondant à 00/01/10/11 par exemple.
Et ainsi de suite…
Au delà de la complexité ajoutée à tous niveaux (microelectronique, firmware des controleurs), forcément, on voit bien le problème sur la durée de vie des données:
Dans l’idéal, les cellules ne devraient pas avoir de fuite de charge. Sauf que dans la réalité c’est pas le cas et que cela croit avec le nombre de cycles d’effacements subis (par secteur, vu que l’effacement n’est possible qu’a ce niveau sur une flash), en prime! De même, l’effacement devient également de plus en plus lent (un marqueur assez précis de l’usure, pour des flash que l’on peut accéder directement et non au travers d’un contrôleur, d’ailleurs).
C’est ainsi que les datasheet qui expriment la durée de rétention des données vont donner en général un min et un max: Typiquement entre 1 et 10 ans.
10 ans c’est pour une flash neuve, 1 an pour une flash qui arrive au maximum du nombre de cycles d’effacements spécifiés… Les temps d’écriture (à cause des temps d’effacement préalables) sur gros fichiers (non masqués par le cache) vont aussi exploser.
Le final pour les SSD (flash cachées derrière un contrôleur de stockage) c’est en général qu’ils se mettent en read-only. Ne pas les mettre dans un coin trop longtemps pour le backup en se disant que ca reste lisible: Le temps de rétention des données n’est peut-être plus que de quelques mois.
Possiblement moins si le controleur a des timeout d’effacement des secteurs de flash sous-jacente large par rapport au min de la spec.
Sur des tests destructifs, je suis arrivé à ce que le lendemain des secteurs bourrinés parfois au delà du quintuple des spec (sur des SLC, ce qui prends du temps car elles sont généralement spécifiées à 100k cycles quand des MLC sont sous les 5k cycles) aient déjà leur contenu perdu.
Avec parfois des surprises: Un wear leveling (basique) au niveau composant. Un graphe des temps d’effacement secteur (sur qq secteurs en test, non la totalité du composant) monte linéairement, puis après qq milliers de cycle baisse instantanément au niveau d’un secteur neuf et ainsi de suite.
Certaines flash SPI dans les gammes “automotive” implémentent ce genre de mécanisme, évitant de créer des “points chauds” sur des applications on on accède les flash en direct (pas à travers un contrôleur bloc gérant la flash, avec ses bugs possibles) en mode brut avec un mapping figé, sans système de fichier au dessus de la flash pouvant gérer un wear leveling: On retrouve en fait une flash translation layer qui va faire apparaitre au lieu d’un secteur physique, un secteur logique. Et tous les 5k cycles typiquement, le secteur logique ne tombe plus sur le même secteur physique qui s’est retrouvé à héberger des données bougeant peu. Tant que le volume de données souvent écrit est très inférieur à la capacité de la SPI, cela fonctionne. Là, à plusieurs millions de cycles même pas mal!
#14
Sauf que ce qu’ils n’ont pas du tester, c’est le temps de rétention de ces données: Les specs sont toujours conservatives, mais quand on dépasse de plusieurs fois le nb de TBW spécifié en quelque mois le contenu peut alors être irrémédiablement perdu.
Mais bon, en général on aura jeté le bidule avant car il sera devenu excessivement lent.
Ces disques QLC sont typés stockage pur, avec des requis de performance donc pas forcément très élevés. Mais dans les faits, un HDD classique sera bien moins cher et potentiellement plus sûr pour cet usage dans un environnement ou il ne subit pas de chocs.
#15
Bon, vivement qu’ils perdent un zéro sur le prix !
#16
Un 0 après la virgule ? De 900.00€ à 900.0€ ?
)
(pas taper, j’ai bien compris ce que tu voulais dire… mais je doute que ça soit pour demain !
#17
Un grand merci à tous les commentaires très constructifs ci-dessus, pour répondre à la question que j’avais posé.
#18
L’usage type de ce genre de SSD? Les stockages S3 locaux de grande taille qu’on ne purge jamais: les lacs de données.
En général, ce qui justifie cette appellation entreprise est une garantie sur les temps d’accès et une fiabilité accrue. Le 1er point se vérifie souvent. Le deuxième….
Perso, 0.1 DWPD pour 15To, c’est quand même 1 DWPD s’il faisait 1,5To ou 4DWPD s’il faisait 400Go. Donc selon le tarif et selon l’usage qu’on en fait, c’est parfois plus intéressant qu’un petit disque avec une force endurance. A voir donc….
#19
ça douille quand même ^^
#20
Il y a 3-4ans ans, un disque dur 2-3To c’était 200-300€ (en 15K) mais on les achetait forcément par 3 mini (pour le RAID) et même par 6 (baies en redondance)
Et chaque disque ajouté augmentait aussi le prix de maintenance annuelle du SAN…
Au point que payer 300€ n’était pas du tout le problème, c’était le reste.
Et expliquer aux utilisateurs que eux payaient 100€ un disque chez carrefour mais que pour nous c’était 1000€ à investir pour la dispo…+ le coût annuel.
Ca, c’était pour les disques rapides. Les disques lents étaient plus abordables. Les SSD en cache primaire étaient hors de prix.
Au final, pour avoir des perfs et du stockage, on achetait par exemple 2 SSD, 8 disques rapides, 16 disques lents.
Là, avec des SSD de 15To, on peut ne plus avoir à réfléchir à certaines problématiques (le cache SSD est-il suffisant?) et se passer de tiering sans sacrifier en perfs, en stockage, et sans pleurer sur la conso électrique.
Vu le prix de maintien de 2 baies de 16To, la place occupée et la consommation électrique + échauffement (donc la clim), j’imagine facilement convaincre mon ex directeur qu’on pourrait utiliser seulement quelques SSD et avoir tous les avantages… même à 900€ pièce!
#21
j’ai encore quelques disques en 10krpm/15krpm au garage, pas très gros mais bien véloce, après je me pose toujours la question de la durabilité, un HDD est, en théorie fait pour fonctionner plus longtemps, j’ai bien dit en théorie, surtout dans un serveur ou une workstation ou c’est quasi du h24, les ssd ont une tolérence a un certain nombre de To par jour, d’ou la question…quand je vois crucial par exemple, qui garantie ses ssd 5 ans, et après ? les HDD que j’ai tournent toujours impec…
#22
J’ai des HDD qui tournent toujours et qui ont largement dépassé les 15 ans. Est-ce que ce sont des exceptions? Aucune idée. Mais à part au début des SSD où des erreurs de firmware ont pu les bloquer définitivement et autres scandales des TLC samsung, j’ai une confiance plutôt aveugle dans les SSD.
Premièrement, les charges de travail pro ou perso que j’ai pu rencontrer n’ont aucune chance de fatiguer un SSD.
D’ailleurs, j’ai un SSD que j’ai utilisé pendant 6 ans en tant que cache disque système (donc forte tendance à écrire), ce SSD a 8 ans maintenant et ne présente aucun signe d’usure grave (juste les compteurs d’allumages et de nombre d’heures et d’écritures).
Deuxièmement, en environnement pro, et dans le cas que je connais dans un SAN, les conditions sont extrêmes niveau chaleur, et des disques on en changeait très régulièrement. Donc la fiabilité du HDD payé une blinde, c’est limité de mon point de vue.
#23
Durée de vie moyenne constatée : 10 ans. Maintenant c’est basé sur 1 échantillon….
#24
au garage un 146.8 et un fujitsu 73GB
#25
Effectivement, c’est pertinent. Un SSD qui n’est pas usé ont une rétention de combien ? Quid des HDD ? Si j’en laisse un traîner dans un tiroir plus de 10 ans, risquerais-je de perdre de données, et comment ?
#26
J’ai été surpris de lire que QLC = lent, car on écrit 4 bits d’un coup par cellule, en tous cas on en lit 4 d’un coup, donc pourquoi ça devrait être lent ?
(ma question s’adresse plutôt à David_L)
Je n’ai pas compris ta question. Quand on utilise un SSD comme cache, pourquoi avoir besoin de RAM ?
Un SSD permet justement d’avoir des perfs importantes sur une BDD sans avoir besoin de RAM, puisque les IOPS font x 100 au moins (on peut même dire x 500 souvent). La RAM n’empêche pas les écritures (il y a des “commit” qui les forcent), mais est plutôt utile en lecture.
En fait ce serait plutôt l’inverse.
Merci pour le résumé des liens (j’avais vu un autre article du genre il y a des années).
#27
C’est une statistique fiable (à la IHU de Marseille ;-) ) basée sur UN échantillon, j’ai dans mon PC fixe un SSD Intel X25-M de 80 Go acheté en 2009, c’était déjà du MLC (cf https://ark.intel.com/content/www/fr/fr/ark/products/56601/intel-ssd-x25-m-series-80gb-2-5in-sata-3gb-s-34nm-mlc.html ), j’y ai mes partitions systèmes (des Linux) et du /home, dont les caches de Firefox et de l’IMAP de Thunderbird, et la swap, et il tient bien le coup.
J’ai changé de carte mère depuis, la nouvelle pourrait utiliser un SSD NVMe mais finalement j’ai fait une petite économie en gardant mon bon vieux SSD, de toutes façons tellement plus performant que n’importe quel disque magnétique.
#28
Typiquement, les spec brutes des flash vont indiquer entre 1 et 10 ans. 10 ans pour des secteurs de flash n’ayant pas subi de cycles d’effacement, 1 an quand on en arrive au nombre de cycles max d’effacements spécifiés. Mais bon, c’est assez dépendant aussi des conditions d’usage et en particulier des températures subies. Les specs restent généralement très conservatrices. Mais se méfier, pour un SSD (flash derrière un contrôleur bloc ou autre, au delà du composant flash derrière dont l’utilisation réelle est difficilement quantifiable faute d’attaquer les flash en direct), d’un modèle qui a subi très largement son nb de TBW (Tera Byte Written) global spécifié.
Il marche, mais gare aux données! Même (et surtout, le FW ne peut cacher la merde en ré-écrivant plus souvent quand détection d’erreur, encore, corrigible… avant que ce ne le soit plus) quand il ne sert pas!
#29
Les systèmes de cache SSD réservent de la RAM pour garder le plan du cache. Ils sont assez simples à priori, et le résultat c’est que la RAM nécessaire augmente avec la taille du cache.
Mais les contrôleurs sont très limités en RAM. Donc le cache risque de ne pas passer ou de couter trop de RAM.
-> Mieux vaut les utiliser en tiering. Mais à ce prix et avec ces perfs, mieux vaut plus petit et plus rapide à mon avis.
Quand aux serveurs SQL: je suis d’accord. Les SSD permettent de limiter la RAM nécessaire pour faire tourner la BDD. Et sur une infra virtualisé, c’est double gain, car la mémoire vive est réservée aussi sur le stockage pour permettre les migrations/mises en veille/SWAP.
De plus, le débit d’un RAID SSD dépasse rapidement le débit réseau des machines (souvent encore en 1x1Gbit/s). Donc si les requêtes n’ont pas trop de jointures, ça peut passer crème.
#30
Dans un SAN qui brasse des To par jour: 4 SSD en tiers 1er niveau, (256Go - RAID 1 - 2 baies, SLC par contre) + infra VMWare avec des SSD locaux pour le cache disque, les migrations.
En 3 ans: je ne compte plus les disques durs changés sur les baies ou les serveurs. Aucun SSD changé.
Encore 3 ans plus tard: visiblement les SSD n’ont jamais été changés.
Remarque: le tiering est remis en cause chaque semaine par la baie, mais les SSD prennent dans la figure les recalculs d’index et écriture BDD notamment. Et ils sont bien au chaud, l’armoire avec les baies de stockage posant quelques problèmes de refroidissement (perso je proposais de faire sécher le linge derrière, on aurait pu sécher quelques centaines de kg /j je pense)
Bref, que ce soit perso ou pro, je pense que les SSD sont très fiables, plus que les HDD. Et j’ai surtout utilisé du SSD en cache (donc avec plein de lecture/écriture aléatoires), un domaine où leurs performances font une différence même sur de vieux systèmes, mais qui est censé les fatiguer plus vite.
#31
Merci pour ces éclaircissements, très intéressants !
C’est vicieux, car autant une perte de données on s’en rend compte assez rapidement, autant des fichiers aléatoirement corrompus, c’est tout de suite moins visible. Et ce sera souvent trop tard lorsqu’on le remarquera, même avec des sauvegardes (car il est rare de garder un historique des sauvegardes sur 10 ans, à moins d’avoir beaucoup de place)…
Aurais-tu des liens ou des articles pour approfondir ce sujet ? Des applications pour tester la rétention du disque ? On n’en parle pas assez alors que c’est crucial, davantage que le nombre de cycles d’écriture, à mon sens.
#32
nan c’est bien ça, une cellule mlc est écrite bien plus souvent qu’une cellule slc :
en slc, si 1 bit d’un fichier change, on récrit la cellule
en mlc, si n’importe lequel des x bits change, on réécrit la cellule
sur 1 octets maintenant :
8 cellules en slc vs 2 cellules en qlc
si on change 1 bit, chaque cellule slc à une chance sur 8 d’être réécrite, c’est une chance sur 2 pour les deux cellules de qlc
#33
non non tu te trompes, car en SLC un octet prends 8 cellules, et 4 cellules en MLC, et 2 cellules en QLC. Donc sur de la QLC, on use moins de cellules.
#34
Tu confonds la RAM de l’ordi avec la RAM présente dans le SSD.
Pas sûr d’avoir compris ce que tu voulais dire.
#35
Il n’y’a que des pb :
l’amplification d’écriture, si tu écris en aléatoire par ex, sur un SLC tu ne vas user que les bits accédés, en QLC aucune raison que tes bits aléatoires soit dans la même cellule donc tu vas écrire 4x plus de données sur les voisins (pour récrire un bit tu devras réécrire les 3 autres bits de la cellule).
Le WearLeaving a 4x moins de place : L’algo de wearleaving est en charge de répartir l’usure, hors un SSD QLC à 4x moins de celulles adressables qu’un SLC de taille égale: L’usure sera beaucoup plus élevée en QLC, et les perf vont se dégrader plus rapidement.
Tu oublies la physique !
Lire une cellule est plus lent en QLC qu’en SLC il faut détecter 16 niveaux de courant c’est beaucoup plus compliqué / lent qu’un SLC qui raisonne en binaire (au-dessus d’un niveau c’est un 1 peu de risque d’erreur) et peu passer moins de temps à interpréter / corriger les niveaux. (avec 16niveaux de courants les erreurs doivent être élevées, et les algos de correction essentiels). Autre détail les cellules sont empilées en 3D en QLC donc potentiellement en contact avec plus de courant de fuite en provenance de cellules voisines.
Pour écrire c’est la catastrophe le contrôleur doit :
Bref une lecture en QLC serait logiquement 4x plus rapide qu’un SLC, sauf qu’en pratique la lecture est 16x plus précise, il y’a 16x moins de marges d’erreurs, et beaucoup plus de facteurs perturbateurs qui entrent en jeux (état précédent de la cellule, courant de fuites lors de l’écriture de cellules voisines…)
#36
cf également la réponse de fofo9012
on use peut-être moins de cellules, mais on les use 4* plus en qlc qu’en slc
imaginons que sur notre octet précédent on change tous les bits en 8 étapes :
en slc, chaque cellule aura été écrite 2 fois (enregistrement initial, puis modification de chacun des bits
en qlc, chacune des 2 cellules aura été écrite 5 fois (et encore, en considérant que l’écriture initiale ait été faite en un seul coup car les 4 bits auraient été regroupés par le contrôleur), donc l’écriture initiale, puis chaque modification d’un des bits de la cellule
#37
Je ne te suis pas non plus ici.
On accède à un disque par secteur, historiquement 512 octets, maintenant 4 k ; on ne s’amuse jamais à changer quelques bits comme ça. Avec le SLC ça modifie (au moins) 512 cellules, avec le QLC ça modifie (au moins) 128 cellules.
Ça ne change pas ce qu’on appelle l’amplification en écriture.
Sinon pour tes explications générales rien à redire. La lecture est en effet plus délicate quand il y a 16 niveaux à détecter, mais pas sûr que ça soit un phénomène plus lent. On lit un voltage, ce qui prend un temps donné (idem SLC ou autre me semble), après c’est l’interprétation (par le contrôleur) qui est plus délicate. L’écriture surtout doit être plus compliquée pour s’assurer que le bon niveau est atteint précisément (enfin de mémoire - sans jeu de mot :-) ).
#38
(me suis foiré dans ma 1ère réponse)
Je ne te suis toujours pas (et cf mes explications dans le commentaire précédent).
#39
J’oubliais d’indiquer que sur un SSD, on efface par quantité minimale relativement importante (genre 128k) et on écrit par groupe de secteurs (pour diverses raisons), entre 8 k et 16 k d’un coup par exemple.
#40
l’histoire de 512 octets / 4k, c’est pour les disques à plateaux, c’est plus fin sur les ssd
cela dit il y a une histoire d’accès par “page” et par “bloc” pour la flash, je sais plus si une page contient des blocs ou l’inverse, et il me semble qu’on peut écrire par l’un et lire par l’autre, et/ou “effacer” par l’un de ces regroupements (c’est là que le trim intervient, pour éviter de réécrire le tout à chaque modification, on écrit ailleurs le bloc ou la page, et le trim vient effacer de temps en temps quand toutes les données ont été réécrites dans d’autres pages / blocs au fur et a mesure des modification, quelque chose dans ce goût la de mémoire)
par contre je sais plus si une page / un bloc c’est un regroupement qui se compte en bit ou en cellule (probablement cellules, ce qui participe à ces soucis d’amplification d’écriture)
edit : je guettais ta modification, je pensais pas que tu referai 2 message à la suite, tes 128k et 8k / 16k ça doit etre les page et blocs dont je parle
#41
Oui et non, car le SSD continue à se prendre des requêtes de l’ordi avec la granularité la plus fine au niveau du bloc (512 ou 4096 octets donc), parce que c’est fait comme ça côté OS.
Le trim c’est plutôt l’indication au SSD qu’un bloc (ou un groupe de blocs) a bien été libéré par le filesystem et qu’on peut réécrire dessus, car le SSD n’a aucune connaissance de l’organisation par le filesystem, il se contente de lire et écrire des blocs à des emplacements (la vision globale d’un périphérique de type bloc - c’est-à-dire un disque).
#42
Donc au final, on a beaucoup de FUD, car ce que fait réellement le SSD est bien différent du principe “je lis en A12 et je réécris en A12” car A12 est déjà une adresse virtuelle.
Remarque: certains disques dur le faisaient déjà, avec une technique d’écriture sur l’emplacement libre le plus proche, à la file, puis une réécriture plus tard, quand on a le temps, au bon endroit.
#43
pour l’histoire des disques “qui le faisaient déjà”, y’a plusieurs choses, les SMR qui écrivent dans un cache CMR puis déplacent les données quand ils ont le temps, et les systèmes de fichiers qui font du “copy on write” comme par exemple le btrfs.
c’est au moins 2 cas où on a un comportement vaguement similaire de pas écrire à l’emplacement lu
effectivement mon exemple était un cas théorique pas super optimiste, mais le principe reste valable :
si un bloc est un regroupement de 8 cellules, en slc on va se retrouver à écrire dans un nouveau bloc (donc “user” 8 cellules”) à chaque fois qu’un bit d’un octet change, si c’est de la qlc, le même nombre de cellules va être usé, mais ça sera à chaque fois qu’un bit change parmi 4 octets
dit autrement, en slc on va avoir 4 blocs au lieu d’un seul en qlc pour stocker 4 octets, donc si on fait plusieurs changements d’un bit aléatoire dans nos 4 octets, en slc on aura moins d’usure des cellules individuelles vu qu’il ne faudra réécrire qu’un seul des 4 blocs, en qlc c’est le même bloc qui sera sollicité à chaque fois pour la même quantité de données stockées et modifiées.
tilt
en fait voila le souci :
pour “user” la totalité des cellules d’un ssd il “suffit” d’écrire 1 bit dans chacun des blocs, donc avec des blocs (pour l’exemple, j’ai pas les bonnes valeurs, exemple pour simplifier) de 8 cellules (1 octet), sur un ssd de 8Mo, il faudrait modifier 1Mo de données.
en qlc, 0.25Mo suffisent a déclencher l’écriture dans chacun des blocs, vu qu’un bloc ne contient pas 1 octet, mais 4 …
je sais pas si c’est plus parlant pour exprimer les défauts de la qlc par rapport à la slc
#44
Ca c’est clair.
C’est juste que physiquement, dans la vie réelle, il est très difficile de quantifier les écritures réelles dans les cellules. Finalement, il est possible que dans le monde pro les conditions soient plus favorables: écrire beaucoup d’un coup peut être profitable face à écrire un peu toutes les secondes.
Par ailleurs, dans le monde pro, le overprovisionning est assez conséquent (30%, y compris sur les disques durs: des disques de 320Go rapportaient une taille sans overprovisionning de 500Go), ce qui compense un peu les effets nocifs d’écritures “collatérales” - et limite l’augmentation d’usure en cas de disque plein. Enfin, les contrôleurs SAN, RAID et les disques et SSD dédiés ont parfois des firmwares adaptés - comprendre que l’écriture et l’allocation seront optimisée par rapport au matériel, pas par rapport à l’OS qui reste souvent avec des blocs de 4ko(donc ni la taille d’une piste de DD ni d’une ensemble de base de cellules de SSD).
Bref, je dirais: pas de panique, le QLC semble être encore viable pour de très nombreux usages (sauf peut-être dans les Tesla https://tesla-info.com/blog/tesla-mcu1-emmc-failure.php :-) )
#45
Ne compare pas un SSD à un eMMC ;) Ca n’a rien à voir hormis le principe technique…
#46
Tout à fait.
D’ailleurs à un autre niveau (sans vouloir embrouiller les esprits), on a en plus certains filesystem journalisés qui font ça (rien à voir avec les SSD, ça date d’avant), il ne réécrivent pas sur un bloc donné, mais l’écrivent ailleurs et ensuite changent un pointeur dans leur structure. Une base de données SQL a en général ce genre de comportement.
Je crois que fry en a parlé juste après toi.
Tu es coincé sur ton histoire de bit qui change…
Mais ce n’est pas comme ça que ça se passe. L’OS écrit par bloc de 512 octets, à la base (ou 4096 à présent dans certains cas), donc à partir du moment où tu as des données à écrire (soit des nouvelles, soit un contenu qui change avec une lettre au milieu d’un paragraphe), ces données sont envoyées avec cette granularité ; et ensuite le SSD fait au mieux pour regrouper les écritures dans son cache RAM avant d’écrire ça par blocs plus importants (l’histoire de l’effacement par 128 k et d’écriture par 8 ou 16 k).
Donc à supposer que tu veuilles changer 1 bit dans un fichier, de toutes façons côté SSD ça va engendrer une modification bien plus massive de cellules.
#47
Ne crois-tu pas qu’un périphérique dont le principal défaut est l’usure ne compare pas ce que tu écris avec ce qu’il y a d’existant pour ne pas réécrire ? J’ai tendance à croire que si ;)
#48
Je suppose que tu plaisantes là :-) .
Je rappelle qu’un SSD ne peut qu’écrire par blocs de taille relativement importante, et il ne va pas lire avant d’écrire, aucun disque ne fait ça puisqu’on ne lui soumet que des ordres de lecture ou d’écriture (lire ou écrire tel bloc - ou groupe de blocs contigus - à partir de tel endroit).
#49
Absolument pas ;) Je me dis que c’est possible pour limiter l’usure. Tu sais ce qu’il y a dans ton contrôleur? Moi pas. Entre ce qu’il te présente (un disque de X Go de données) et la réalité (un amas organisé de données déconstruites), il serait bien malin de pouvoir deviner.
Même si oui, si pignoler sur des bits ne sert à rien au niveau usage, puisque la réalité est bien plus macro.
#50
Encore une fois tu mélanges les couches d’abstraction, on accède à 4k d’un coup au niveau informatique (OS), mais quand tu écris ton secteur de 4k, le contrôleur du SSD lit ces 4k (en fait en général le secteur a été lue par l’OS précédemment donc il est probablement déjà en cache au niveau du contrôleur) et n’écrit que les cellules dont les valeurs ont été changés. Donc je réitère ce que j’ai écrit précédemment quand on met à jour 1 bit en SLC on écrit effectivement qu’une seule cellule d’un bit.
C’est parfaitement faux : Justement un SSD n’est pas un disque, le contrôleur peut précisément lire n’importe quelle cellule du SSD (comme une RAM), il doit même lire la valeur car le temps d’écriture dépend des données précédentes : s’il n’y’a que du 0 sur la cellule et que tu dois monter de 16 niveaux de voltage il faut “écrire longtemps”, à l’inverse si tu dois changer qu’un seul niveau il faut que ce soit trés bref pour ne pas dépasser le niveau attendu.
Évidemment côté OS le plan d’adressage n’est pas au bit sinon il faudrait une table d’adressage aussi grosse que le disque-dur et une consommation de RAM astronomique (ça aussi c’est un truc que tu n’as pas saisi soit dit en passant)
Physique : les transistors ne sont jamais complètement ouverts ou fermés (courant de fuite)
Electronique : On arrive à stocker de 2 à 16 niveaux de voltage en jouant précisément sur le degré d’ouverture de la porte
Le contrôleur physique “bas niveau” : peut lire un transistor et selon son voltage sortir son niveau binaire (1 à 4 bits par transistor) et plus compliqué écrire ces niveaux en jouant sur le temps / voltage d’écriture ajusté à l’état des cellules voisines. Imagine que tu fermes / ouvres une porte de maison entrebâillée en soufflant dessus : si tu dois fermer / ouvrir complètement tu peux y aller comme un bourrin au souffleur à feuille (SLC), si tu veux passer de 22.5° à 45° d’ouverture il faut être assez subtile sur la force et le temps du souffle (QLC), et surtout connaître précisément le degré d’ouverture avant de souffler dessus.
Le contrôleur logique “haut niveau” : gère une table d’adressage au secteur (4kb) quelles cellules stockent quel secteur, il permet de lire et écrire via le contrôleur bas niveau et es chargé des optimisations : mise en cache, limiter l’usure (ne pas réécrire des cellules déjà au bon niveau), assurer une usure régulière (Wearleaving : à partir d’un niveau d’usure, ou de taux de réécriture des cellules déplacer le secteur ailleurs) et enfin suivre les secteurs morts contenant des cellules inutilisables.
Côté contrôleur / OS un SSD est vu presque comme un disque on y lit / écrit des secteurs de 4k.
#51
merci :)
il me semble quand même que l’écriture se fait par bloc ou page sur la slc, donc effectivement si un bit change c’est pas une unique cellule qui est usée mais quand même le nombre de cellule qui forme un bloc (ou une page)
j’aime beaucoup l’analogie de la porte, très parlant et bien trouvé
#52
Tu m’as l’air de connaître des choses (de tes commentaires) mais là tu me sembles un peu bouché :-)
Un contrôleur SSD ne PEUT pas faire ça, car pour réécrire n’importe quel bit quelque part, il doit commencer par effacer tout un groupe de blocs (page) autour. Et même s’il n’y avait pas besoin d’effacer, pour l’écriture c’est pareil, c’est par groupe de blocs, ça atteint facilement 8 ou 16k.
Tout le reste, le wear leveling, l’écriture par niveaux fins (QLC) ou pas (SLC), etc, je connais aussi. En 2000 pour de l’embarqué j’avais déjà regardé les algo de répartition d’écriture et d’usure.
Je ne comprends pas comment il peut connaître correctement certains aspects techniques du SSD et ne pas connaître la façon dont les cellules sont effacées et écrites (par page effectivement).
#53
“il” … c’est moi ?
XD
y’a des concepts de je peux comprendre / mémoriser et oublier certain points pour d’autres
on parle bien de l’usure des ssd
le contrôleur ne peut donc écrire que par page si je te suis bien (je savais plus si c’était page ou bloc, mais bref), là on est d’accord
à chaque écriture sur le ssd, c’est donc une page complète qui va être écrite quelque part, et donc “user” les cellules de cette page
pour 2 ssd de capacité identique, il y aura 4 pages en slc, pour une seule en qlc, donc hors écriture “consécutive” (j’ai un trou, c’est quoi l’opposé d”écriture aléatoire déjà ?) il y a 4x moins des pages sur lesquelles répartir l’usure
#54
Non, celui à qui tu répondais (fofo), à qui je venais de dire qu’il connaissait pas mal de choses, sinon j’aurais dit “tu” :-)
Du coup il y a quiproquo, je ne te “reprochais” rien.
écriture séquentielle ou linéaire.