Reprise du message précédent :
ohcto le défaut de ton dessin c'est qu'il compare un secure erase avec une suppression de données. Il aurait mieux valut le faire avec un formatage complet du SSD, non ?

Tu as raison, le trim ne ralentit pas les écritures. J'ai du mal m'expliquer, j'ai jamais dit que trim ralentissait les écritures.
Ce que je voulais montrer c'est pourquoi certaines personnes disent que le secure erase "restaure les performances" du ssd.
 
La raison c'est qu'après un secure erase, tous les blocs de mémoire sont immédiatement utilisables, donc t'as les même performances que lors de la première utilisation.
 
Si tu fais de la place en supprimant des fichiers ça se fera via trim, et même si tu les données en questions sont marquées invalides,
vu qu'elles sont éparpillées physiquement dans le ssd, le firmware doit déplacer les données valides pour libérer des blocs utilisables,
et vu qu'il fait ça en même temps que tu écris sur le disque, ça ralentit un peu les écritures.

Si il y a qu'une seule partition ça revient quasiment au même vu que l'OS va trimmer tout l'espace logique.

 

 
Niveau OS ok !
 
Le problème c'est que justement, un SSD implique d'autres notions pour tout ce qui est question de vitesse I/O.
 
Un bloc marqué comme vide par l'OS, l'est ou ne l'est pas sur le SSD et c'est là que le bas blesse. Si l'OS considère qu'une zone est vide alors qu'elle ne l'est physiquement pas sur le SSD, ça plombe les performances ; c'est là que le trim intervient.
 
Deux cas lors d'une écriture sur un SSD : a) on efface, b) on réécrit par dessus (genre mise à jour d'un fichier après édition) dans le cas (a) le trim marche lorsqu'il est fonctionnel, dans le cas (b) cela ne marche pas à tous les coups. Dans le cas (a), sans trim, seules les données issues de la FAT ou MFT sont mises à zéro et pas tous les blocs (chute rapide de perfs avec XP ou vista). Dans le cas (b) c'est nettement plus complexe, je ne maitrise pas tous les aspects, ce que j'en ai retenu, c'est que le trim marche rarement. Donc, de nombreuses zones marquées comme libres par l'OS ne le sont physiquement pas sur le SSD -> Dégradation des perfs à plus ou moins longue échéance.
 
Le fait de parler de trim et de secure erase est antinomique : le secure erase sur un SSD remet toutes les cellules à zéro et remet donc le SSD à vide comme à l'origine. Le trim n'a pas lieu d'être dans ce cas précis. Le trim n'étant qu'un palliatif à un manque de l'OS d'effacer réellement les données du support et de n'effacer que les "entêtes" et clés d'entrées des tables.
 
Le secure erase se fait simplement et très rapidement sous windows 7 sur n'importe quel SSD : la commande diskpart est en partie faite pour cela, je vous ai fait un petit screen il faut la ligne de commande en mode admin
 

 
Attention de ne pas se planter de disque c'est imparable et ça ne demande pas de confirmation
 
 
 

 
1) non
2) oui
3) non, à part de le faire 10 heures par jour sur 6 mois
4) absolument pas, ça ne changera strictement rien qu'il soit vide ou plein
 

Avant une réinstalle, je fais juste un clean avec diskpart pendant l'installe. c'est mieux de faire un clean all?
 
Merci

Tout dépende de ce que tu attends Que veux tu faire ? Il n'y a pas de mieux ou de moins bien, il y a juste une commande qui correspond à ce que tu veux faire ou pas

Remettre le SSD à 0, un "secure erase" en gros

 
 
Non non non non !
 
Il y a beaucoup trop d'erreur, tu confonds trop de notions
 
 

 
Vrai
 

 
joli néologisme
 
 

 
Tout va dépendre de ton SSD... Tu as quoi comme modèle ?
 
J'ai fait cette mise à jour sur le topic SSD :

 
Le trim ne ralentit pas les écritures, il se fait après l'écriture, il prend du temps, mais c'est invisible puisque post write.
 
D'après ce que je viens d'écrire, tu peux comprendre que le secure erase est efficace dans la mesure où il remet effectivement à zéro les cellules alors que toute autre opération d'écriture/effacement venant de l'OS ne le fait pas : partitionnement, effacement, formatage, etc. Donc oui, le secure erase remet le SSD à l'état neuf (hormis les cellules déjà physiquement dégradées).
 
En ce qui concerne le wear leveling, il est à noter qu'il existe deux variantes dont le détail n'est pas forcément connu par tout le monde : le protocole statique (global) et le dynamique. Le mode dynamique est plus rapide, plus simple mais moins efficace quand à la durée de vie du SSD. Le statique ou global est très complexe et bien plus lent mais permet une longévité nettement accrue.
 
Le fait que ce paramètre augmente sans cesse est tout à fait normal, c'est même la base intrinsèque du wear leveling
 

 
 
VRAI !
 
l'éparpillement des données est une notion à complètement abandonner lorsqu'on parle de SSD. Cela n'a pas de sens
 
Non, là c'est incorrect, le contrôleur ne déplace rien, surtout avec le trim actif qui gère l'espace libre et l'a déjà effacé.
 

 
 
Dans ce cas, il faut effectivement un clean all

Vas-y explique les choses à ta manière pour voir.    
 

Je sais pas d'où tu sors de telles affirmations. C'est effrayant...  

Non, je ne vais rien expliquer... Désolé, documentes toi

Ok.

840 250Go utilisé sur mon mediacenter, il contient win8.1 + jeux steam, le multimedia est sur le HDD

sans faire le mec qui fout la merde, j'aurais bien aimer avoir ton explication histoire de ne pas rester sur l'illustration de hocto  
j'aime pas les mecs qui gardent tout pour eux  

A ta disposition, demain je détaillerai ce que tu veux

Je ne crois pas garder tout pour moi justement, depuis 15 ans que je suis là... Ce que je n'ai pas apprécié ce sont les smileys

Comme Master te l'a très bien dit, samsung magician fait parfaitement son travail

PS : es-tu sûr que les drivers microsoft gèrent le trim ?
Quelle version de nForce SATA Controler ?

Edit : hop, cadeau bonux, un screen de samsung magician

trimcheck indique que le trim fonctionne avec le driver microsoft
nforce 11.1.0.43
ce que fait magician c'est pour palier la non gestion de trim sous xp vista ?
j'ai lu sur un forum english de faire une images disque, un secure erase et restaurer l'image

sous XP c'est aussi une façon de faire...
mais une chose que je ne sais pas, c'est si le clonage fait une défrag en même temps.

logiquement pas besoin de défrag pour du clonage vu que tout est écrit à la suite par secteur.

 
?
 
l'éparpillement des données sur un SSD, ce n'est pas un problème hein, mais alors pas du tout!

oui tout est écrit secteur après secteur...  
donc d'après toi, ça conserve la fragmentation?

 
oui.  
un logiciel de clonage ne fait aucune défragmentation

Non, pas besoin de faire d'image !
Le screen que j'ai mis te montre l'option à exécuter : optimisation. A faire de temps en temps.

Je pense que le fait que trimcheck t'indique un trim actif ne garantit pas que le trim soit actif sur toute la ligne, je verifierai.

Ce que fait magician n'est pas uniquement valable pour xp & vista. C'est aussi valable dans ton cas.

[/quotemsg]

Ce n'est pas un problème effectivement parce que c'est la nature même du SSD renforcé par le wear levelling et par le mode LBA.

Je confirme. Ce serait même dangereux qu'il touche un tant soi peu à l'image qu'il crée. Cette image doit rester la plus identique possible à la source.

Desolé pour le triple post, mais le multiquote ne marche pas

quand tu vas restaurer l'image , les fichiers ne seront pas fragmentés.
En plus on ne défragmente pas un SSD donc la question en se pose pas.

Si.

Sinon cpagrave, sous 8 la defrag lance un trim manuel sur un SSD. Donc de temps en temps tu lance une defrag sur ton SSD, après être repassé en pilotes MS par contre.

Merci

Oui, du coup hier soir, j'avais oublié de préciser le coup de win 8.1 et de son trim manuel lors du defrag

Bon puisque c'est la deuxieme personne qui me corrige sur ce point, je vais faire un petit schéma.

Déjà par éparpillement mettons nous d'accord,
éparpillement = les données appartenant à une range d'addresse (logique) contigue est stockée sur des blocs (physiques) mémoires différents.

L'éparpillement des données n'est pas un problème pour la lecture c'est vrai, et c'est un des gros avantages par rapport aux HDD.

Par contre pour l'écriture ça peut poser problème.

1. Supposons qu'une donnée (orange) soit enregistrées par l'os aux addresses 1~5 (pas d'unité, c'est juste une vue simplifiée)
    Au niveau de la mémoire, ces données peuvent être stockées dans des blocs physiques différents (ici 4).
   
    Nb: les blocs en violet représentent l'OP

2. La donnée en question est supprimée et l'os trimme les addresses 1~5.
    -> Le SSD marque les données comme invalides.
    Le problème c'est de l'espace a été libéré mais concrètement cet espace n'est pas utilisable.
    Pourquoi? Parceque les blocs qui contiennent les données invalidées (rouge) contiennent aussi des données valides (bleu) et pour réclamer l'espace libre généré par le trim,
    il faut déplacer les données valides avant de pouvoir effacer les blocs en question (un peu comme quand on déplace les oeufs d'une barquette avant de la jeter à la poubelle!).
   

3. L'utilisateur/OS veut écrire de nouvelles données (en vert)
    Le SSD va stocker ces nouvelles données sur un bloc disponible (indiqué par la flèche)
   

4. Mais si l'on ne veut pas se retrouver en rade de blocs disponibles, il faut collecter l'espace libre.
    pour ce faire, il doit déplacer toutes les données valides des blocs qui contiennent des données invalides vers de nouveaux blocs
    et ce procédé engendre beaucoup d'opérations au niveau de la mémoire.
   
    Dans notre exemple, il faut 15 copies (lecture + écriture) pour pouvoir générer 1 bloc disponible.
    (à la fin il en reste 2 mais vu qu'il on en a consommé 1 au départ, on ne compte pas le 2ème)

5. Situation finale:
   
    En conclusion, pour pouvoir écrire 5 données, le controlleur a du copier 15 données
    et ça se traduit inévitablement par un débit en écriture ralenti.

Ensuite c'est sûr que si il y a de l'idle time le controlleur peut collecter l'espace libre sans que l'utilisateur ne le ressente, mais c'est un autre débat.

Finalement, pour revenir sur la question de l' "éparpillement", tu comprendras bien que si les données trimmées étaient stockées physiquement dans le même bloc mémoire,
il n'y aurait pas eu à faire tant de copies pour obtenir de l'espace disponible à l'écriture.

ohcto je pense que tu occultes le fait que certaines opérations se font en background.

Oui, ca se fait en background
En background = en même temps que l'utilisateur écrit sur le ssd

SAUF s'il y a des periodes où le disque n'est pas sollicité, auquel cas ces opérations peuvent éventuellement se faire à l'avance,
mais la façon dont le ssd va se comporter dépendra des fabricants et je ne parle pas de ce cas là.

v

 
Ok, mais à moins que je ne maîtrise pas la notion de wear leveling, j'attire ton attention sur la faible quantité de donnée écrite sur le disque: 10 fois sa capacité. Comment alors ce paramètre a pu passer à 98 (départ 99 ou 100) ?
 
 
EDIT:
Je complète par ces données=>
 
Le 20-03-2014:
(Wear leveling : current value = 99;  Raw data = 22) pour 433Go écrits
 
Le 20-07-2014
(Wear leveling : current value = 98;  Raw data = 41) pour 610Go écrits

Je suis pas a même de commenter ces valeurs,
mais la quantité de donnée écrites physiquement sur le média n'est pas égale à la quantité de données écrites par l'utilisateur.

La quantité de données écrites sur la mémoire flash peut être bien plus grande que les valeurs affichées dans tes infos smart.
Le rapport va dépendre de divers facteurs (principalement de l'OP de base de ton SSD, du taux de remplissage moyen et de si ta config supporte le trim ou pas).
-> http://en.wikipedia.org/wiki/Write_amplification

je me tate pour le 840 Pro 512 Go , mon souci c'est que le 850 Pro sort bientôt....
je sais pertinemment qu'en utilisation courante et hors bench je ne verrai aucune différence entre les 2 , surtout qu'avec la promo RDC , le 512 Go revient à 289€ contre 399€ pour le 850 Pro , ca fait une sacré différence de prix en plus !
 
mais voilà c'est mon côté  Geek qui a envie du 850 Pro !
 

 
Quelle est la question  

La voie de la raison suivre tu dois.  

 
en fait y en a pas , c'était un post comme ça car je sais pas comment faire
Comme le dit Diamond , il vaut mieux que je suive la voie de la raison !

@ohcto  : trop tard
j'ai resisté et j'ai pris un 840 Pro de 512 Go en remplacement de mon actuel 256 Go qui va finalement aller chez le voisin
du coup entre la revente de mon  840 Pro 256 Go (100€) et la promo RDC avec le code SAM36 (-36€) , le 840 Pro 512 Go m'est revenu à 189€

  cette solution me convient, je ferai donc ca

 
si c'était vraiment le cas, logiquement il y aurait une baisse de performances dans le temps donc?
hors mon 840 pro 256 Go tourne toujours comme une horloge. Pourtant je lui en ai mis plein le tronche, il est plein à 70%, 7 To d'écriture, grosse installation windows, téléchargement comme un bourrin sur le SSD, etc etc..... et voilà le résultat :
 

 
et à l'utilisation aucun ralentissement non plus, rien.  
 
donc?

Tu me dis qu'on s'en fout de l'éparpillement des données sur un ssd, je t'explique que cette affirmation n'est vraie qu'en lecture
et je prends le temps de détailler quel impact ça peut avoir en terme de fonctionnement interne sur les écritures, c'est tout.

Je suis content que tu aies un bon score CDM.

 
oui, et je t'explique que je ne ressens aucune baisse de performance, ce que semble confirmer crystaldiskmark.
 
donc?