Reprise du message précédent :

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.

trop tard screené le flood spabien.
 

Allouer, désallouer?
Même si le second terme est un néologisme créé par les informaticiens...
 

C'est bien sympa tous ces commentaires a lire mais qu'en est il du dernier firmware 1245 ?

 
Non, si ton fichier couvre le secteur LBA 1000 à 2000, contigus vu du FS (pour se simplifier la vie, sinon la fragmentation FS provoque plusieurs appels Trim pour chaque fragment contigu), et qu'en interne le SSD a mappé la plage LBA 1000-2000 aux pages 40000-40010, 900-980, 85010-85020, il ne va pour commencer que retirer ces entrées des tables de mappings.  
edit: donc en fait oui, mais pas tout le temps, et surtout ça permet de le faire de manière incrémentale.
 
Que les pages restent aux précédentes données on s'en fout, c'est comme faire un free() d'un bloc mémoire, tu n'efface pas les données du bloc, tu change juste la structure de description des plages d'espace utilisé.
 
Si des pages libérées appartiennent à un block partagé avec des pages encore mappées, bin de manière simpliste ça reste comme c'est. ça gêne pas.
 
Ensuite si par la suite de la libération de pages, le SSD détecte un regroupement trivial possible de secteurs LBA fragmentés d'un point de vue mapping, pour les ramener au sein d'un même block, augmentant les perfs pour les futures lectures et ou écritures des mêmes secteurs, et libérant de nouveau pages/blocks libres, il a le choix de le faire toute de suite, ou d'attendre une période d'activité I/O basse.
 
Ce qui compte c'est qu'au fur et à mesure des Trims, la table des mappings se simplifie, les pages libres puis les blocks libres émergent, et les prochaines écritures séquentielles OU aléatoires se retrouvent simplifiées, puisqu'elles peuvent de nouveau taper directement avec le max de rendement (sans recombiner) dans des blocks libres.
 
Maintenant il faut aussi voir comment le wear-levelling joue sur l'ensemble, et si il impose pas des tournantes de blocs de temps en temps même lorsque il y a pléthore de blocks libre.

Déjà c'est 1275 et si tu étais allé faire un tour sur le forum d'OCZ comme un grand tu verrais qu'il n'est pas dispo.  
 
ça ne saurait tarder d'après le fofo OCZ, that's all ^^

 
Ouais, je sais pas trop sur quel pied danser en ce moment entre le français, le franglais léger, le franglais gerbique, et le n'imp

je suis en train de regarder les ssd, et j'ai besoin de quelques infos :
- quel controleur éviter ?
- quel est le meilleur rapport qualité/prix ?
utilisation gaming/bureautique

Et pourquoi Marc et Stéphane se décarcassent à faire des tests ?

http://www.hardware.fr/articles/75 [...] b22-j.html

http://www.matbe.com/articles/lire [...] if-de-ssd/

 
Deja c'est une question, je te remercierez bien de me repondre gentillement, quelle est cette mentalité que l'on trouve ici chez certains?? enfin bref... ben le fofo je veux bien mais je ne suis pas bilingue premièrement et secondo ma question s'adressai eventuellement a ceux qui aurait pu avoir l'occasion de le tester(beta ou autre)...
 
Merci qd meme

<Question con>
Si le problème de chutte de perf en écriture séquentielle viens d'une bordelisation des tables d'allocations, un defrag ne peut pas réparer ça ?
</Question con>
 
Edit : La gestion des fichiers pas Windows (ou autres) et la gestion interne au SSD sont totalement séparées c'est ça ? Donc un defrag par l'OS ne débordelise pas les tables d'allocation internes du SSD ?

bah le dernier article de marc sur le sujet déconseille un ssd dispo et conseille un autre qui ne l'est pas encore
par contre je n'avais pas lu l'article de matbe, merci pour le lien

 
Je n'ai pas dis qu'il devait le faire de suite Mais il faut bien le faire à un moment ou un autre. Ou alors cela ne joue qu'au niveau des blocs libres. Ce qui est déjà pas mal en soit, mais dans ce cas l'explication d'AnandTech est à la masse (puisque jamais on ne lira/effacera/réécrira un bloc partiellement utilisé pour accélerer la prochaine écriture de la page devenue libre dans ce dernier).

 
De rien  
 
EDIT: et pas besoin d'être bilingue pour lire "Vertex Firmware Update 1275 now available." sur le fofo OCZ. Enfin bref....

 
Si c'est de ça dont tu parles:
http://www.anandtech.com/storage/s [...] =3531&p=10
 

 
C'est évidemment faux: Le Trim sert à démapper. Toute conséquence ultérieure est le fait de la stratégie du firmware, et plus précisément faire un clean des pages libérées n'a aucun strictement aucun intérêt fonctionnel (autre que la confidentialité, mais pour ça on a le secure erase).
 
Après je sais pas si il a voulu faire une vulgarisation, mais au vu de son histoire du "je lis le block, j'efface la page, j'écris le block avec la page d'effacée", il a pas l'air d'avoir assimilé la différence entre une donnée et la référence à une donnée.
 
Secure Erase = Trim (démapping/désallocation) + effaçage (à 0 ou aléatoire) des pages/blocks impactés pour confidentialité
 
D'ailleurs des firmwares supportant le Trim (même sans l'OS l'utilisant tant que Seven ou kernel Linux n'est pas arrivé), ça permettrai d'optimiser de manière cheap en usure et en temps un SSD, puisque il suffirait de:
 
- faire une image ghost du SSD
- Trimmer tout l'espace LBA avec un outil pour (la table des mappings se retrouve vierge, sauf peut-être les infos de wear-levelling)
- ramener l'image ghost sur le SSD (en espérant que ghost ne fasse pas d'écriture sur l'espace libre, ce qui provoquerai des mappings inutiles)
 
Ce qui explique qu'en attendant y'a que le Secure Erase qui permet de cleaner le SSD, mais au prix d'un peu plus de temps, et d'usure des cellules. (enfin bon une écriture ou un erase de block spa dramatique)
 
Comme ghost écrit les fichiers de manière séquentielle, on aurait une fragmentation FS basse, un mapping trivial, et des blocks non mappés pour que le firmware respire.

Mmmm si si ca à un interêt fonctionnel (celui qu'il présente d'ailleurs), mais bien faible comparé aux écritures supplémentaires que cela nécessiterait.

C'est surtout que son explication est fausse  (edit: l'erase peut peut-être éviter d'avoir a le faire plus tard, mais bon )
Dumoins il rajoute des étapes inutiles, et ignore les étapes critiques.
Ca sous-entends que le Trim touche aux pages/blocks des données comme un Secure Erase.
 
Il touche a des pages/blocks mais par effet de bords: ceux où le firmware place ses tables de mappings (et qui doivent être commises très tardivement en flash après modification, période de basse I/O par exemple).
 
Ce qu'il faut comprendre c'est que comme la page est libre, le firmware fait du meilleur boulot.
C'est ce que j'essaye d'expliquer depuis le début    
 
Et dans un contexte réel avec plein de petits fichiers créés/réécris via le FS, le Trim à la suppression des fichiers peut permettre au firmware de retourner aux perfs initiales.
Par contre si c'est un benchmark aléatoire bas-niveau qui passe pas par le FS, les mappings resteront en vrac

Je suis en train d'installer Photoshop et je suis sur firefox en même tant, je ressent des freezes ...
J'ai un sumsung MLC 64Go.
Genre la quand j'écris ya des lettres qui viennent après que je les est tapé mais la souris elle reste fluide...

Oui enfin bon faut pas dramatiser je pense.
Photoshop est super lourd.
 
Avec un HDD tu aurais peut-être eu même pire comme comportement.
 
Par contre si ca se confirme lors d'un usage plus classique, alors c'est qu'il y a un prob.

 
Il installe Photoshop, il l'utilise pas

sur les SSD en SLC, il y a juste les puce qui change ou y aussi autres choses? (sans parler des controlleurs Jmicron bien sur)
 
car sur les SLC il n'y a pas tout ses problèmes qu'on peux rencontrer sur un MLC....

 
On est d'accord, de base rien que le fait de désallouer les pages permettra d'avoir de meilleurs résultats en écriture sur un disque utilisé. Mais du coup le gain n’a bien entendu rien à voir avec ce qu’il mettait en avant mais vient de ça :
 
Exemple 1 : Bloc de 4 pages (0,1,2,3), toutes contenant des données, mais 0 et 1 étant obsolètes (fichier effacé). Disons que le système de fichier veut écrire dans la page 0 :
 
Sans trim :
1/ Lecture (du bloc complet ou alors des pages 1,2,3 ?)
2/ Effacement du bloc
3/ Programmation des pages 0,1,2,3
 
Avec trim :
1/ Lecture (du bloc complet ou alors des pages 2,3 ?)
2/ Effacement du bloc
3/ Programmation des pages 0,2,3
 
Donc là normalement il y’a déjà un gain à l’étape 3, peut-être à l’étape 1.
 
Exemple 2 : Bloc de 4 pages (0,1,2,3), toutes contenant des données, mais 0 et 1 étant obsolètes (fichier effacé). Disons que le système de fichier veut écrire dans la page 0 mais aussi dans un LBA correspondant à une page située dans un autre bloc
 
Sans trim :
1/ Lecture (du bloc complet ou alors des pages 1,2,3 ?)
2/ Effacement du bloc
3/ Programmation des pages 0,1,2,3
+ On doit en même temps faire une autre opération de lecture/effacement/programmation pour l’autre page à écrire.
Avec trim :
1/ Lecture (du bloc complet ou alors des pages 2,3 ?)
2/ Effacement du bloc
3/ Programmation des pages 0,1,2,3, la page 1 contenant l’info qui devait être écrite dans un autre bloc mais qui arrive ici (write combining+réorganisation de la table LBA)
 
Non ?
 
 
 

Oui je sais.
Je me suis mal exprimé, mais quand j'ai dit super lourd c'était pour dire a de tas petits fichiers. Même un HDD classique ca le met à genou je pense.

 
L'idée est effectivement que le firmware ne devrait lire et écrire que les pages strictement nécessaires et pas aussi celles qui sont obsolètes, et faire sa petite defrag incrémentale.
 
Mais il faut aussi intégrer le wear-leveling qui fait que tu vas peut-être (probablement) pas effacer/écrire le même bloc, et donc provoquer des réorganisation des tables LBA assez régulièrement. (enfin c'est pas un effet de bord lié au trim)
 
-----
 
Accessoirement d'où le fait qu'un contrôleur sans RAM doit être obligé de commettre beaucoup trop fréquemment ses updates de tables en flash. (Ou être moins jongleur avec les données et louper des opportunités de regrouper les secteurs)
 
Encore plus accessoirement, je pense qu'il serait même intéressant pour le contrôleur, de recouvrir le chargement des pages depuis la flash source avec l'effacement du bloc de la flash de destination. (et donc d'avoir les données qui jonglent d'une flash à l'autre), enfin bon là c'est boule de crystal pawa

Samsung MLC "ancien" après 1 semaine d'utilisation en disque système XP avec 2-3 jeux
 

 
Un test moins bon (average -30mb/s) qu'il y a 1 semaine cependant à l'utilisation aucune différence   .

Tu n'avais même pas besoin de dire "aucune différence", puisque ce test est séquentiel, et on sait bien qu'en utilisation quotidienne en tant que disque système le séquentiel compte pour peanuts. Même avec un séquentiel à moins de 50 tu ne sentirais aucune différence AMHA.
EDIT - sauf bien sûr en cas de R/W séq. de gros fichiers, comme des gros niveaux de jeu par exemple.

Pour ceux qui hésitent à prendre un SSD, je vous ai fait une vidéo du Samsung MLC   .

Il  y as t'il une différence de perf entre 1 seul ssd et 2 ssd en raid 0 en tant qu'os système ? Avez vous des liens de test réel (vitesse d'exécution des programmes,temps de boot, extraction winrar...) pour comparer entre 1 seul et 2 disque.merci

La lecture ca ne bouge pas sur le temps
 
La zone a 175 Mo/s est fausse et correspond à la lecture de cellules vierges

A votre avis que vaut-il mieux choisir entre :
- Samsung MLC 1ère génération 64 Gb : la valeur sure d'un certain côté, que l'on trouve à 200 euros.
- Vertex (ou équivalent Super talent moins cher) 64 Gb qui apparemment pose pas mal de problème mais a des performances supérieures.

 
Même si c'est un peu dur, attendre que les défauts de jeunesse se tassent.
Sinon regarder des valeurs sûres, mais il n'y en a pas tant que ça en MLC non?
C'est surtout en SLC qu'on a moins de pb. Là pour les prix, fouille ouille ouille.

Tu me conseillerais donc d'attendre que le vertex arrive à maturité ?
C'est exact, j'en connais même qu'un seul qui a été conseillé vivement et il s'agit du samsung non ?
Concernant les SLC, je possède 2 OS (Linux + Windows) donc 32 go ne me suffisent pas et je ne suis pas pret à mettre plus de 200 euros dans une geekerie

 
C'est pas nécessairement le vertex...
Concernant les tarifs, ce n'est qu'une question de temps. Quand je vois le prix d'une clef usb 8Go aujourd'hui, et la même taille il y a 12 et 24 mois...
Je parle bien de deux critères: fiabilité/performances correctes et prix qui sont importants pour moi.

Ou carrément une valeur encore plus sûre, la version SLC qu'on trouve à peu près au même prix en cherchant bien sur ebay (neuf).
 

je me demande combien d'années on va encore entendre que l'achat de ssd est un truc de geek...
 
ssd = achat intelligent, pas de geek

C'est pas une question de geek ou pas. C'est une question de prix au go 40 fois plus élevé. Même si on utilise pas un ssd pour le stockage mais sur une partition "de travail" qui est plus petite, ça fait mal aux fesses un tel prix au go.

t'expliqueras ça à l'étudiant fauché qui à le choix entre mettre 60€ dans un HDD 640Go ou un SDD 32Go avec contrôleur JMicron pourri.  

Bjr  
 
Pour une utilisation du ssd en disque principal ( internet/bureautique/jeux ) sans comparaison de prix/taille  
 
il faut mieux prendre un slc mtron 3500 ou un mlc ocz  vertex    ?
 
merci de vos avis  

 
C'est marrant, on dirait moi  :  
J'ai fait le choix du Jmicron pourri et... oui, le controleur est naze mais en bidouillant "un chouilla" on arrive à en faire quelque chose... mais ce disque est la pour donner un petit coup de boost sur un pc vieillissant, et il ne touchera pas ma futur config. C'est possible de faire disparaitre les freezes en utilisation normal, par contre ca n'arrive pas à la cheville d'un vertex d'après ce que j'en vois en cas de méchants pics d'i/o (même si ca reste quand même souple, c'est généralement possible de faire une install tout en naviguant sans freeze, faut juste pas faire grand chose à coté) Pour une utilisation basique c'est bien, les programmes se lancent bien plus vite que sur un disque conventionnel, les chargements en jeux sont super rapides mais faut quand même avouer : le jmicron, faut pas trop le brusquer
 
Un truc de geek? Oui et non. C'est pas indispensable mais une fois qu'on y a gouté... Je dirais que c'est comme un écran 22' ya quelques années, des gros défauts à moins de faire péter le portefeuille mais une fois qu'on y est passé, plus moyen de revenir en arrière.    
 
Ca ne sera plus un truc de geek quand on trouvera des ssd à la moitié de leur prix actuel. L'utilisateur lambda n'est pas prêt à claquer 200€ pour un disque de 60go même ca un confort énorme par rapport à un disque conventionnel. Mais les prix vont se casser la gueule, faut juste pas craquer sur des trucs trop chers  

sa ne seras plus un truc de geek quand on en trouveras dans les PC de supermarché  

 
si tu as la possibilité, prends un SLC mais autre qu'un mtron 3500, qui n'est pas vraiment trés perf (Mtron a merdé un chouilla sur celui la ^^)