Reprise du message précédent :
Et en 2009 vous croyez encore les chiffres annoncés par les constructeurs ?    
 
(vous voulez qu'on en reparle dans 140 ans, ou bien on dit que beaucoup de ces SSD auront rendu l'âme bien avant ?   )

Ben écoute 50Go par jour sur un SSD de 32Go (en supposant que ces 32Go soient libre), ca fait en théorie une utilisation de 1.5 fois d'une cellule mémoire par jour.

Fois 365 jours dans l'année et 140 années tu arrives à 80 000 écriture d'une cellule, ce qui correspond plus au moins à la durée de vie théorique d'une cellule SLC.
Mais effectivement ca reste des stats, une cellule mémoire peut tout aussi bien te crever sous les yeux au bout de 5 minute. Tout comme une disque dure aussi...

En tout cas ce que montre le calcule c'est que pour les SSD il vaut mieux avoir beaucoup de mémoire libre, un SSD presque plein est a éviter)

(PS: années bissextiles non pris en compte dans le calcule        )

 
et alors ? Meme si il dure que 5 ans on aura changer de matos d'ici la...

 
si tu relis mon post, tu verra que j'ai écris EN THEORIE    
 

 
D'où l'importance du Trim, car sinon le SSD suppose que tous les secteurs qui ont été écrits dans le passé sont toujours utilisés

Prix des OCZ Apex
"Les capacités disponibles sont de 60, 120 et 250 Go à des tarifs annoncés de 199.99, 369.99 et 829.99 dollars respectivement."

http://www.matbe.com/actualites/57 [...] -les-prix/
 
Mais pas de cache...

Mouai....
 
En Gros : Apex = Core V3

 
J'aurais dit Core², car raid interne de core

Oui mais sans cache  

En tout cas je suis curieux de voir comment ils font leur raid interne

Une puce Silicon Image (port extender je crois) qui permet de faire du Raid 0 ou Raid 1 sur deux HDD/SSD à partir d'un unique port SATA.

Non?

EDIT:
Utilisé sur des cartes Raid genre Dawicontrol DC-5200
http://www.dawicontrol.com/flyer/dc-5200raid.pdf

Toujours rien sur les Vertex alors ?

Pour le raid (0) interne sur le SSD a priori c'est deux jmicron ,1 par chaque face de 32go (si 64go) + et un chip raid de la même marque je crois.

A voir.
Jmicron ne dispose pas encore de contrôleur Raid basé sur un Sata Port extender. Mais bon possible que ce doit un nouveau modèle.
Moi je parie plus sur du Silicon Image.

 
D'où l'intérêt de parler de Core² qui rappelle bien que ce sont juste deux cores intégrés, et les cores n'ont pas de cache.
 
Concernant le raid interne, ben le contrôleur interne doit fonctionner comme une carte raid sans cache je suppose.
admettons qu'il y a deux faces de puces flash, une face correspond à un disque, l'autre à l'autre disque. ensuite le contrôleur
réparti les stripes de données comme un raid0. On peut imaginer qu'au lieu de faces, ce soit un raid puce par puce, tout dépend du nombre
de canaux que le contrôleur peu gérer à la fois.
 
Je suppose que le X25M avec ses 10 lignes concourantes fonctionne un peu sur ce principe de raid interne. je peux me tromper biensûr
(idem pour le X25E )

Je suis surtout curieux de savoir combien ils vont le facturer.
Parceque Chip supplémentaire + SATA 6Gb/s => $$$$

Les Apex ne sont pas SATA 6 Gb/s

Oki autant pour moi

1. Admettons que ce raisonnement corresponde à peu près à la réalité (je n'en suis pas sûr mais admettons).
 
Maintenant admettons que le SSD est "raisonnablement plein" à 80% (quand on achète un disque ce n'est pas pour le remplir au quart). Cela diviserait en théorie la durée de vie par 5 non ? Soit 28 ans. Cela reste très raisonnable.
 
Maintenant passons aux MLC qui supportent environ 10 fois moins d'écritures par cellule. Cela ne ferait plus que 2,8 ans de durée de vie constructeur pour un SSD MLC plein à 80% (ou 1,4 ans pour un SSD MLC plein à 90%)...    
 
La conclusion dans ce cas-ci serait (encore une fois) que si on veut vraiment être tranquille dans le temps il vaut mieux prendre du SLC.    Ou bien faire appel à d'autres solutions pour éviter la perte de données (RAID 1 ou 5 de MLC, backup des données importantes sur un DD traditionnel, etc.).
 
 
2. ... mais comme je le disais au départ, je ne suis pas sûr que ce raisonnement soit bon. J'ai discuté avec un ami à moi assez calé sur la question, et voici sa réponse :
 
Ça ne marche pas comme ca. Les sites qui parlent du Wear Leveling disent souvent n'importe quoi :
 
Le contrôleur du SSD ne peut pas savoir quel est l'espace libre ou non partitionné car il n'a aucune vue sur le système de fichiers. Il ne voit que des entrées/sorties de bits a certaines positions, mais c'est l'OS qui gère la couche entre le contrôleur et les partitions. Donc il n'y a pas de notion d'espace libre au niveau du disque hardware.
 
De plus le Wear Leveling des SSD permute 2 blocs si il se rend compte que le premier est souvent écrit. Donc il peut être a 99% plein de données, ça ne gène en rien son mécanisme interne de permutation de bloc.
 
La conclusion ici est plus optimiste : les SSD SLC comme celui dont on a annoncé les chiffres constructeur retrouveraient une durée théorique de l'ordre de 140 ans en utilisation intensive, et les SSD MLC une durée théorique de l'ordre de 14 ans pour le même type d'utilisation. Le tout indépendamment du taux de remplissage du disque. Merci le Wear Leveling !    
 
 
Et maintenant la question à 100 balles : où est la vérité ?...  

La vérité est ailleurs
 
Tant que l'on a pas 10 ans de stats en arrière, on aura du mal à estimer la durée de vie de ces disques.

Pour ceux qui n'avaient pas vu cette nouvelle, il existe un logiciel d'estimation de durée de vie pour les SSD à contrôleur JMicron: JSMonitor.
 
http://d.hatena.ne.jp/Lansen/20081220
 
Download direct: http://www.ne.jp/asahi/lansen/web/ [...] or0.2b.zip

Je suis curieux de savoir comment il estime...

 
Effectivement le firmware ne connait pas ou mal l'espace libre, sauf si l'OS utilise le.... Trim.
Bon OK je suis relou
 
Maintenant pour un SSD MLC grand public, je pense que l'obsolescence posera problème avant l'usure.
Et que de toutes manières seul le recul du temps permettera d'évaluer la fiabilité.

c clair, la théorie c'est une chose...
 
c'est la pratique qui compte
on a oublié un élément essentiel : la qualité des composants... qui il me semble varie entre les modèles.... et ça, bon courage pour l'évaluer
 
 
ceci dit merci pour ces explications, meme si on en est toujours au meme point ("jsais pas on peut pas dire" ), c'est intéressant

Honnêtement j'y connais rien au système de fichier.

Néanmoins j'ai une question.

Au fond c'est bien le contrôleur qui écrit les donnée dans les cellules. Il sait donc lesquelles sont sollicitées.
Donc est-ce que le contrôleur n'ont pas une sorte de table avec des statistique d'utilisation des différentes cellules? Et font leurs choix en fonction de ces valeurs?

Non, non, pas du tout, puisque c'est un mot qui est apparu plusieurs fois dans le topic et auquel je n'ai pas encore compris grand-chose (mais j'ai peut-être lu en diagonale). Une explication simple et schématique serait donc la bienvenue.
 
Enfin si, peut-être un truc : le Trim est quelque chose qui sera peut-être utilisé par Vista ou Seven, mais pas franchement par XP non ? Or comme je compte utiliser XP pendant encore de longues années, ben le Trim...

Quand tu achètes un SSD neuf, en interne il n'y a pas de mappings "tordus" entre les secteurs LBA et les pages des mémoires flash.
 
Au fur et à mesure que tu remplis ta partition, et que tu fais des opérations d'écritures, les tables se complexifient, a chaque ecriture le SSD essaye de faire le wear-leveling: aller écrire sur des zones rarement inutilisés.  
Lorsque l'OS écrit des lots de données inférieurs aux tailles de pages, le firmware doit relire la page englobant le petit lot de données, combiner et écrire la page a nouveau (voir à l'echelle du block effacé). Généralement combiné au wear-leveling, il va écrire la page/bloc actualisé a un nouvel endroit non utilisé.
 
Le problème est que si tu remplis un SSD au max, ça réduit l'espace utilisable par le firmware puisqu'il est obligé de conserver tout ce qui a été écrit.
 
Ce qui veux dire que si ton volume, monte à 99% d'utilisation, le firmware aurait moins de marge pour ses opérations et ralentira (et génèrera des opérations de maintenance interne bloquantes plus fréquemment).
 
Le problème est que si tu dégages des données coté système de fichier, le firmware SSD ne le sait pas. Donc même si tu libère de la place sur ton volume pour n'en utiliser que 30%, le firmware SSD verra toujours les 99% crêtes que tu as anciennement atteint.
 
Le "Trim" viens là: L'OS signale au SSD quel "surfaces" LBA ne sont plus utiles (dû aux surpressions, formatage, defrag, etc...), et le firmware récupère l'espace pour ses opérations interne qui pourront du coup se faire de manière plus souple.

A mon avis, ton explication ne tient pas la route... Ce que tu décris c'est le dynamic wear leveling et c'est très déconseillé sur de tels supports de données.
 
Ce qui devrait être utilisé si les ingénieurs qui conçoivent ces produits réfléchissent un minimum, c'est le static wear leveling, méthode décrite quelques posts auparavant. Le contrôleur va garder une trace du nombres d'écritures sur chaque bloc et répartir les données de façon à ce que l'utilisation soit statistiquement identique sur tous les blocs.  
 
C'est certainement bien plus complexe que ça mais ce principe permet de garder une durée de vie semblable pour toutes les cellules... Et, à première vue, ça ne doit pas être bien compliqué à implémenter.

Oui, mon copain qui s'y connaît m'a dit aussi que le Static Wear Leveling est la bonne solution pour que la durée de vie des SSD ne soit plus un pb et que leurs performances restent constantes dans le temps.
 
Maintenant il faudrait que quelqu'un qui s'y connaisse vraiment puisse nous expliquer de façon simple la différence entre :
- Dynamic W.L.
- Static W.L.
- Trim

 
J'ai pas cherché a spécifié le type de wear leveling. J'ai cherché a mettre en évidence l'apport du Trim pour le firmware. (C'était la question de Rosé à la base )

Franchement le Trim je dis non merci. Je préfère un bon contrôleur hardware qui est dédié à cette tâche plutôt que de confier ça à l'OS et que ce soit fait de manière software. Cette deuxième solution, en plus d'être moins performantes qu'un contrôleur hardware, prendrai des ressources processeur...

Drap je

 
T'as pas compris ce qu'était le Trim, mais je vois pas comment l'expliquer autrement

Quand je disais qu'il faudrait des explications claires et simples.

Bon, je m'y essaie :
 
En Static Wear Levelling, le SSD essaye d'avoir une usure constante sur le SSD et vérifie pour chaque donnée écrite le meilleur endroit ou la placer. Il a le choix entre des zones vides (jamais écrite), des zones écrites "fixes" (genre les datas d'un jeux) et des zones écrites "variables" (swap, par exemple).
 
En temps normal, il va monitorer tout ça et essayer de placer les données dans une zone vide (si elle existe) ou dans une zone écrite peu usée.
 
Le problème, c'est qu'à un moment, on n'a plus de zones vides et donc le SSD passe son temps à déplacer des cellules "utilisées" pour optimiser le tout.
 
Mais utilisées, ça veut juste dire qu'on a écrit un jour dessus, mais c'est peut-être vide pour le système : tu copies un truc sur ton SSD, puis tu l'effaces (depuis ton système), le SSD il verra une zone utilisée statique, il ne sait pas ce que fait ton système d'exploitation.
 
Avec les trims, l'OS va pouvoir dire à ton SSD que ce que tu viens d'effacer, ce n'est plus une donnée statique mais une donnée effacée, donc qu'il n'y a pas besoin de la déplacer à un autre endroit, donc on gagne en rapidité (surtout sur les SSD beaucoup utilisé).

Mmh je trouve ca bizarre tout de même.

Alors le problème est le même avec un disque dure.
Il va écrire les données sur le bord extérieur et continuer toujours à aller vers le centre du disque (moins perf) même si à l'extérieur du disque des donnée ont été effacé par le système. mmmh  

non, tout simplement parce qu'avec un disque dur classique le système de fichier connait la structure du disque dur (qui est linéaire) alors qu'avec un SSD le système de fichier est indépendant de la façon dont les données sont stockées.
 
Sur un disque dur : tu écris sur le secteur 345, le système de fichier est capable de connaitre son emplacement physique, il est écrit sur le secteur 345 du disque dur.
 
Sur un SSD : tu écris sur le secteur 345 dans la logique du système de fichier, mais pas dans le secteur 345 physique, c'est le firmware du SSD qui décide, et les trims, ça permet de faire un choix plus rapide.

Donc le ssd fait du defrag en permanence et l'os lui raconte sa vie en lui disant caypabien.
 
bon je garde mes raptor

en gros, oui, même si c'est pas du defrag en réalité, c'est juste une optimisation pour garder une usure constante.
 
Et pour utiliser SSD et Raptor assez souvent, le SSD est bien plus réactif (le bon SSD, évidemment)