Reprise du message précédent :

 
Bon bin il vend son SSD Samsung SLC 64Go à 300€.
 
Si vous connaissez quelqu'un intéressé pouvez-vous me contacter svp ?

vous le prenez ou hdd erase ?

il est sur le CD Ultimate Boot CD

www.ultimatebootcd.com

 
Je lurke ce topic ssd pour comprendre comment ça évolue. En gros la morale de ton histoire c'est qu'il faudra que tu reformates tous les 6 mois ou bien je n'ai rien compris ? Pourquoi tu as eu cette baisse de performances et n'y a-t-il pas d'autre moyen que le format pour y remédier ?

 
 
Effetivement la perte de perfs en écriture au fil du temps semble inéluctable.
C'est dû à la manière de fonctionner des SSD. Regarde les images sur cette page, c'est assez compréhensible:
http://www.anandtech.com/storage/s [...] i=3531&p=8
 
Mais bon faire un formatage de temps à autre c'est pas plus mal. Je le fais déjà régulièrement avec mes DD.
En plus si tu as vista ultimate tu peux créer une image de restauration de ton système ... ensuite tu fais un "secure erase" pour vider complètement le SSD et tu restaures l'image de vista à partir de son CD d'install. Bref, l'histoire d'une petite heure en tout et pour tout.

N'empêche comment ça se fait du coup que tous les SSD qui actuellement non pas les TRIM ne soient pas impactés par les baisses de perfs?

http://itshop.comquell.at/comquell/index.jsf
 
335 euros le Vertex 120 Go! voilà un prix plus décent et conforme au prix initial annoncé par OCZ

 
C'est aussi une très bonne question...
Aucune explication claire et/ou détaillée du pb n'a été donnée. En plus on a du mal à croire que c'est totalement de la faute des puces flash puisque certains SSD n'ont pas le pb.
Pour ma part, je trouve dommage de claquer pas mal d'argent dans un truc dont les prix chutent a ce point, mais surtout dont on ne comprend pas encore la façon dont ils évoluent.
Si ce n'était qu'un problème d'augmentation des perfs au fil du temps, ça serait comme le reste de l'informatique.
Non là on a une crainte -justifiée ou non, je ne sais pas- sur la fiabilité du produit et des perfs, et assez rapidement.
 

 
Formater ne suffit pas, il faut apparement passer par hdderase
 

 
pourquoi ? c'est une bonne question. Je ne sais pas. L'explication doit se trouver au niveau technique, mais je ne l'ai pas.
Le seul moyen pour retrouver les perfs originales que j'ai trouvé est hdderase.
Format, zero fill, n'ont rien changé.
 
Mais faire une image et restaurer le système ne prend pas beaucoup de temps

en même temps, faut arrêter le mode parano. Car ce qui ne baisse jamais ou qui ne se détériore pas c'est le temps de réponse, principal attrait des SSD. Que les débits max deviennent mauvais, on s'en cogne un peu du moment que le SSD (un bon hein, pas un JMIcron) continue de traiter correctement les petits fichiers sans freezes...

 
Je suis en partie d'accord, reste qu'une explication du problème pourrait justement dissiper tous les doutes. Maintenant, même les fabricants font comme s'ils ne savaient pas. Soit c'est vrai, et c'est dommage, car il va falloir attendre... Soit ils savent et c'est bien dommage de traiter les clients potentiels comme ça. Ou alors la vérité est-elle si affreuse que ça?
 
Si les SSD étaient vraiment pas chers, la question se poserait beaucoup moins. C'est pas le cas.

Tout depend de l'utilisateur. Même si c'est pas critique effectivement, c'est pas non plus quelque chose de totalement sans conséquence. Quand on paye un prix pareil pour du matériel qui finalement ne justifie que si on est geek ou qu'on a des besoins très très particuliers, on est en droit d'attendre quelque chose de fiable et sans mauvaise surprise...
 
C'est comme si sur une ferrari la marche arrière devenait d'un seul coup inutilisable!

Je pense perso que c'est lié à à des firmware orientés I/O aléatoire de manière trop forte.
 
En effet si j'écrit par bloc de 4K de manière séquentielle sur le Vertex par exemple ... pas de souci sur les perfs en accès séquentiel ... par contre si j'écrit par bloc de 4K de manière aléatoire, après les perfs en accès séquentiel sont out.
 
Je reste donc sur mon hypothèse qui correspond a priori également à ce que fait le SSD Intel :
 
Pour pouvoir atteindre le max d'I/O en accès aléatoire sur le SSD, et aussi diminuer l'amplification en écriture, le SSD réorganise les accès aléatoire de manière séquentielle, par bloc de 128K par exemple.
 
C'est à dire que si tu fait 32 écritures de 4 Ko de manière aléatoire sur ton SSD, elles seront en fait écrites de manière séquentielle au niveau des puces FLASH.
 
Pour autant au niveau du système de fichier leur adresse logique (LBA) sera toujours la même. Il y'a donc au niveau du SSD une nouvelle table de correspondance entre LBA et page flash qui est écriture
 
Avant :
LBA 0 = Page 0
LBA 1 = Page 1
LBA 2 = Page 2
etc
 
Après
LBA 0 = Page 0
LBA512 = Page 1
LBA1024 = Page 2
 
Le problème désormais c'est que si tu fait de nouveaux une écriture séquentielle ... elle sera complètement foireuse si elle se base sur un table de la sorte puisqu'elle se comportera comme une écriture aléatoire en quelque sorte
 
Plus les écritures aléatoires sont regroupées par "bloc" important, plus les perfs derrières en écriture séquentielle pourront morfler.
 
Mais c'est réglable au niveau du contrôlleur ... cf. les différent firmware pour les Vertex!

Bien entendu, mais étant donné que tous ne se comportent pas de la même manière à ce niveau, c'est un point à étudier. Car je suis désolé mais tomber à 10 Mo /s en débit max, ca fait quand même bien chier

 
C'est fortement probable.
Le problème c'est que sans déallocations, le firmware tombe rapidement à cours de pages libres pour pouvoir faire du séquentiel réellement séquentiel.
Ca va peut être se terminer par un outil constructeur sur cd bootable ou clé USB, qui déclenchera la relocation des secteurs. Defrag bas-niveau

Je ne suis franchement pas sûr que le TRIM change quelque chose à ca Enfin si il faudrait déallocation puis réorga interne des donnée (bonjour les écritures pour "rien" ).
 
En tout cas je trouve que lorsque OCZ a fait un sondage sur quel FW voulaient les gens, il manquait une partie des infos ... car logiquement les FW qui offraient moins d'IO étaient également moins sujet à ce type de baisse de perfs ... et avoir 300 I/Os en random au lieu de 100 (par ex) n'est pas vraiment utile en desktop.  
 
De même j'aimerais bien savoir quel est le niveau de write combining (128 Ko ? 256 Ko ? 512 Ko ?) ... ca doit pouvoir se tester ... ca va prendre des plombes mais tant pis

N'empeche est-ce que le bon plan ca devient pas l'Intel X25-M? On trouve le 80go a 300 euros maintenant (en Suisse) et les perfs sont comparables voir supérieures au Vertex...

En utilisation desktop franchement il n'y a pas de différence (même avec un "vieux" Samsung MLC / Mtron 3500 d'ailleurs) ... ca booste dans tous les cas.
 
Le peu de diff de perfs en pratique tu risque de ne pas les voir ... par contre les 40 Go de diff plus

 
surtout que les benchs ont parfois tendance à s'emmêler les pinceaux  

As-tu essayé de tester le Vertex avec les firmwares mois I/O pour voir si le problème persiste ? J'ai déjà posé la question, mais pour un usage PC bureautique / jeux / vidéo, donc pas serveur, est-ce que le firmware I/O est le plus adapté ? Peut-être que le firmware intermédiaire entre I/O et débit est un bon compromis pour ce type d'utilisation ?

Arf, encore mieux est le Corsair 128go MLC alors...

On les trouves ou ?

Heeeuuuuuuuu j'ai une réponse mais ça va peut être pas te plaire  

En demandant à Tony peut-être ?

Je croyais que tu pouvais choisir le firmware sur le Vertex, c'est juste livré avec le firmware I/O finalement ?

 

Je pense que tu as bien fait de t'abstenir ^^
 
 
 
Je pense de plus en plus sérieusement à me payer un SSD. Mon budget étant limité je ne sais pas encore pour quelle solution opter...
Ce qui est difficile à appréhender c'est qu'on trouve peu de comparos "étendus". Celui de matbe, par exemple, ne contient que des SSD SLC et donc chers. Et puis le fait que le contrôleur se retrouve rarement (voire pas du tout) sur les fiches techniques des magasins en ligne n'aide pas y voir plus clair.
J'ai vu quelques tests des Patriot Warp (v2) en version 32/64 et 128Gb. Les performances ont l'air honnêtes mais vu le prix je suis sûr que le contrôleur est un Jmicron ... Ceci dit je me demande si ce n'est pas intéressant quand même si le système a suffisamment de ram pour éviter le swap.

 
en 3 lettres ?    
 

Mon problème sous IOMeter sur le solid est réglé. J'ai fait un secure erase like et les perfs sont normales à nouveau. C'est qd j'ai vu le sticker RMA sur les puces que j'y ai pensé...

 
On est d'accord, que le problème c'est que si tu charge le disque avec des écritures aléatoires, et le firmware écrit les blocks lba aléatoires en séquentiel en repoussant la fragmentation dans les tables de mapping.  
 
Si lorsque tu veux écrire de nouveau en séquentiel sur les mêmes secteurs LBA, et que le firmware n'a plus d'espace libre, il devra mic-maquer pour dégager des pages/blocks continus.  
 
Pour moi entre le Trim, dont l'application peut être différée, qui permet de libérer de l'espace libre, par juste un démappage des secteurs LBA au niveau des tables afin de simplifier les écritures ultérieures, et un mic-mac au pied du mur, je choisi largement le premier.
 
Maintenant effectivement dans la situation où grosso-modo tu as un disque rempli à ras-bords de pleins de petits fichiers et de gros fichiers sans jamais les supprimer, le Trim n'aura pas d'effet.  
 
Mais pour moi ce n'est pas représentatif, puisque généralement on a l'habitude d'éviter de bourrer un disque/volume ras-la-gueule d'un point de vue FS.
Donc l'un dans l'autre ça permettera au firmware d'avoir des pages/blocks de libres et de mieux se maintenir.
 
Ce qui serait intéressant comme test, ce serait de prendre un SSD vierge (ou de s'arranger d'avoir un mapping vierge), et de travailler dessus avec une partoche qui ne couvre pas tout l'espace LBA. (genre garder 1~4Go en spare pour que le firmware puisse jouer dessus).
Si dans un tel cas le SSD se comporte mieux, alors le Trim peut aider (à condition que d'un point de FS le volume soit pas bourré de fichiers ras-la-gueule).

Pas bête, mais le contrôleur va les laisser vacants non?

 
Si il est utilisé intelligement, le TRIM permettra en effet de gérer mieux.
 
Mais de base, il ne réglera "que" le problème de réécriture d'une page déjà utilisée par le passé.
 
Bien entendu on pourrait se servir ensuite des pages vierges au sein de bloc pour défragmenter complètement les données et la table LBA, mais a quel coût en terme de nombre d'écriture ?
 

Mmm, on arrivera au même problème, moins vite.
 
Note que ca arrive encore moins vite si on garde 4 Go pour l'utilisateur et 62 pour le spare
 

 
Pour moi si le problème est qu'en écriture séquentielle, le débit s'écroule parcequ'il n'y a plus de block entièrement libre pour avoir un rendement max, la déallocation par le Trim aidera obligatoirement. (Sauf si d'un point de vue FS le disque est utilisé au max)
 
Et le pendant d'une écriture séquentielle ou aléatoire basse c'est justement qu'en interne, le firmware fait énormément de recombinaisons, donc lectures/écritures de maintenance et que le rendement vu de l'extérieur baisse.  
 
Un SSD qui toppe à 200Mo/s avec un mapping vierge, et qui tombe à 100Mo/s avec un mapping fragmenté après une grosse masse d'écritures aléatoires sur la majorité de la surface LBA, c'est pas qu'il est à 100Mo/s en interne, il est toujours à 200Mo/s mais avec sa bande-passante méchamment consommée par des recombinaisons potentiellement inutiles de données, car elles n'en sont plus forcément d'un point de vue du système de fichier !!!
La bande-passante de la flash ne varie pas, c'est le taux de mic-maccage interne devant le débit extérieur observable qui varie.
 
Donc pour moi le coût du Trim, qui ne va impacter que les tables de mapping et non les données obsolètes est à mon avis complètement dérisoire comparé a ce qu'il peut faire économiser en mic-macage interne avec des tables en vrac en terme de complexité et des données balancés de pages en pages.
 
Maintenant l'autre-problème est que si tu passes par un benchmark bas-niveau (qui passe outre le FS) qui couvre tout la surface LBA en écriture aléatoire , par la suite même avec un FS non rempli utilisant le Trim, il faudra un certain temps avant de revenir a une certaine normalité.

N'empeche le trim peu avoir un effet pervers aussi non? Si quand on efface un fichier de plusieurs go il passe quelques minutes par la suite a "effacer" vraiment le fichier sur le disque alors qu'on est passé a autre chose non?

Il n'efface pas le fichier, il simplifie les tables de mapping.
C'est un déallocateur.
 

Oui ca aide si il s'agit de déallocer (ca se dit ? ) des blocs entiers, par contre si c'est pour ne déallocer que quelques pages par-ci par là dans des blocs qui resteraient partiellement utilisés (car avec de vrais fichiers derrière), ca ne marche pas. D'ou la nécessiter alors de "défragmenter".

Oui mais pour en profiter derrière il faut bien que le SSD efface le bloc et reprogramme si nécessaire les pages contenant des données valides, ou alors j'ai loupé un truc.