J'envisage de défragmenter mon disque. Le programme Deffragler me met en garde disant que mon disque est un SSD et que le défragmenter risque d'en réduire la durée de vie.

La fragmentation n'étant que de 14%, est-ce utile de défragmenter ? Qu'en pensez-vous ? Merci pour vos avis.

Bonsoir, inutile de défragmenter un ssd, il faut utiliser l'outil de windows qui te proposera "optimiser" au lieu de défragmenter et là tu peux.
Personnellement et ce n'est que mon avis, defraggler ne sert pas à grand chose, mais ce n'est que mon avis.

Au moins, ce logiciel t'auras prévenu qu'il n'est pas nécessaire de défragmenter un ssd. Ce qui n'est déjà pas si mal.
On dit que la défragmentation d'un ssd peut réduire sa durée de vie.

Bonne soirée

Bjr.

Tout est dit dans la question et la réponse !

On ne défragmente pas un SSD au risque de fortement diminuer sa durée de vie.

Mais chacun fait ce qu'il veut avec son porte-monnaie ......................... surtout que pour l'instant le prix des SSD a diminué mais bon, ce n'est pas parce que les prix sont bas qu'on doit le mettre à la poubelle rapidement.

Non seulement ça ne sert à rien, la fragmentation n'a aucune influence sur la vitesse du SSD, mais ça va flinguer rapidement le SSD.

De toute façon, Windows ne sait pas du tout sur quels blocs se trouvent les données sur un SSD. La MFT pointe sur des blocs virtuels et le contrôleur du SSD déplace les blocs pour uniformiser l'usure.

En plus pour accélérer l'écriture, on peut écrire chaque bit sur un bloc différent du SSD. En défragmentant, tu es en fait en train de fragmenter encore plus.

A la limite , tu nettoies un peu tes fichiers, et tu fais une image en demandant de défragmenter les fichiers pendant la création de l'image (HDClone le fait, je ne connais pas suffisamment les autres "imageurs"), puis tu remets ton image ...

Voilà, c'est tout propre ! Il m'arrive de le faire , mais plutôt quand j’atteins les 30% et plus de fragmentation.

Ceci étant, Daneel Olivaw a tout fait raison.

, https://forum.pcastuces.com/sujet.asp?page=-1&f=20&s=5635&REP_ID=4935159

Gallagh a écrit :

A la limite , tu nettoies un peu tes fichiers, et tu fais une image en demandant de défragmenter les fichiers pendant la création de l'image (HDClone le fait, je ne connais pas suffisamment les autres "imageurs"), puis tu remets ton image ...

Voilà, c'est tout propre ! Il m'arrive de le faire , mais plutôt quand j’atteins les 30% et plus de fragmentation.

Ceci étant, Daneel Olivaw a tout fait raison.

Ça ne sert à rien. Comme j'ai dit avant, c'est le SSD qui décide où va chaque bit, car cela dépend du degré d'usure du bloc. Un fichier même petit, sera fractionné sur plusieurs blocs. Windows ne sait pas du tout sur quels blocs se trouve un fichier queconque. Contrairement à un HDD, ce n'est lui qui décide.

En défragmentant ou en imageant et restaurant l'image, le logiciel de défrag va te momtrer un disque où tous les fichiers se suivent, car c'est ce que la MFT montre, mais ceci n'est que virtuel. Les orceaux de fichiers sont répartis dans les blocs flash selon l'usure de chaque bloc.

Exemple :

Tu veux écrire un fichier de 1 MO.

Le SSD va chercher quel est le bloc le moins utilisé, il trouve un bloc avec 30 écritures, il va mettre 500 Ko dedans, le bloc contigu a subit lui 32 écritures et le bloc suivant 31 écritures. Il va mettre les 500 KO suivants dans le blocs qui a subi 31 écritures.

Tout ça, Windows ne le sait pas. Pour lui, le fichier est dans des blocs contigus.

Quand Windows demande par exemple le secteur 7689, le contrôleur regarde dans sa table à quel bloc ça correspond et retourne le fichier à Windows. La MFT ne pointe pas sur des blocs réels.

Daneel Olivaw a écrit :

Gallagh a écrit :

A la limite , tu nettoies un peu tes fichiers, et tu fais une image en demandant de défragmenter les fichiers pendant la création de l'image (HDClone le fait, je ne connais pas suffisamment les autres "imageurs"), puis tu remets ton image ...

Voilà, c'est tout propre ! Il m'arrive de le faire , mais plutôt quand j’atteins les 30% et plus de fragmentation.

Ceci étant, Daneel Olivaw a tout fait raison.

Ça ne sert à rien. Comme j'ai dit avant, c'est le SSD qui décide où va chaque bit, car cela dépend du degré d'usure du bloc. Un fichier même petit, sera fractionné sur plusieurs blocs. Windows ne sait pas du tout sur quels blocs se trouve un fichier queconque. Contrairement à un HDD, ce n'est lui qui décide.

En défragmentant ou en imageant et restaurant l'image, le logiciel de défrag va te momtrer un disque où tous les fichiers se suivent, car c'est ce que la MFT montre, mais ceci n'est que virtuel. Les orceaux de fichiers sont répartis dans les blocs flash selon l'usure de chaque bloc.

Exemple :

Tu veux écrire un fichier de 1 MO.

Le SSD va chercher quel est le bloc le moins utilisé, il trouve un bloc avec 30 écritures, il va mettre 500 Ko dedans, le bloc contigu a subit lui 32 écritures et le bloc suivant 31 écritures. Il va mettre les 500 KO suivants dans le blocs qui a subi 31 écritures.

Tout ça, Windows ne le sait pas. Pour lui, le fichier est dans des blocs contigus.

Quand Windows demande par exemple le secteur 7689, le contrôleur regarde dans sa table à quel bloc ça correspond et retourne le fichier à Windows. La MFT ne pointe pas sur des blocs réels.

AH ?? je suis un peu pressé la tout de suite mais je ne suis pas certain de ce que tu me dis.

J'ai quand même bien l'impression que HDClone reconstitue les fichiers, et qu'ils sont donc réécrits en un seul bloc, sauf évidemment nécessité d’utiliser plusieurs blocs pour l'inscrire en entier. J'ai bel et bien le souvenir qu'après réinstallation de l'image, j'étais retombé à une fragmentation inférieure à 1%.

maintenant, je confonds peut être image et clone, je dois vérifier.

Tout cela est virtuel. La MFT te montre un SSD parfait non fragmenté, mais sur les blocs, les fichiers sont répartit sur tous les blocs à tour de rôle pour régulariser l'usure.

Je répète que la MFT pointe sur des blocs virtuels. l'OS, quel qu'il soit ne sait pas du tout sur quel bloc se trouve un fichier, contraiement à un HDD.

Pour la MFT, le fichier test.doc se trouve sur les blocs 1236, 1237 et 1238. Le SSD les as mis lui, sur les blocs 6789, 4321 et 98765 qui sont les moins usés.

Quans Windows demande le fichier qui se trouve sur les blocs 1236, 1237 et 1238, le contrôleur du SSD regarde sa table interne et retourne les blocs 6789,4321 et98765.

Sur un HDD, les derniers secteurs à l'intérieur du disque ne seront sans doute jamais utilisés, même après 10 ans, si on ne rempli jamais son disque.

Sur un SSD, TOUS les secteurs seront utilisés à tour de rôle jusqu'à leur nombre limite d'utilisation. La répartition se fait sur le seul critère de l'usure.

La défragmentation n'a aucune influence sur un SSD. Les temps d'accès sont les mêmes, que le fichier soit sur des blocs contigus ou fragmenté en 200 parties.

Mille mercis pour ces précisions "très techniques" ! J'ai au-moins retenu que défragmenter un SSD n'est pas une action à envisager !

Bonjour,

Pour en rajouter une couche.

La défragmentation d'une partition, et non d'un disque, permet de gagner du temps en lecture. Si les blocs constituant un fichier sont dispersés le bras devra se déplacer pour atteindre chacun d'eux. Coût de l'opération : le temps de déplacement du bras plus, statistiquement, celui d'une demi-rotation des plateaux pour atteindre le bon secteur. Ceci se chiffre en ms. Le seul but de la défragmentation est de diminuer la part liée à la mécanique dans le temps d'accès.

Puisque sur un SSD il n'y a aucun déplacement d'organe mécanique il n'y a a donc aucune raison de défragmenter.

Ok, Daniel, je prends tes explications, j'avoue ne pas avoir assez de compétences pour ce sujet.

Merci

@ Daneel Olivaw

Que penses tu de ceci ? : https://archive.newsletter2go.com/?n2g=f7o8174z-m9hm6dae-19f7

Celà apporte un peu d'eau à mon moulin, ou du moins, celà peut remettre en question cette idée qu'on ne peut pas défragmenter un SSD ...

Perso, j'ai la version 21 dont je suis entièrement satisfait depuis de nombreuses années pour mes HDD. Je vais peut être me laisser tenter par une mise à jour.

O&O est connu pour ses logiciels qui s'incrustent et difficiles à éradiquer.

Personnellement, j'ai mis O&O sur liste noire depuis longtemps.

Si tu as bien assimilé mes explications sur le fonctionnement d'un SSD, tu auras compris qu'il est non seulement inutile de défragmenter un SSD, mais que surtout, c'est néfaste pour sa durée de vie.

Aucun défragmenteur sérieux ne proposerait de défragmenter un SSD.

Windows détecte très bien les SSD et la seule optimisation qu'il fait alors est d'envoyer un ReTRIM au SSD pour lui dire qu'il faut remettre à zéro les cellules effacées, si ce n'est pas déjà fait.

Si tu n'es pas convaincu, c'est toi qui paye.

Daneel Olivaw a écrit :

O&O est connu pour ses logiciels qui s'incrustent et difficiles à éradiquer.

Personnellement, j'ai mis O&O sur liste noire depuis longtemps.

Si tu as bien assimilé mes explications sur le fonctionnement d'un SSD, tu auras compris qu'il est non seulement inutile de défragmenter un SSD, mais que surtout, c'est néfaste pour sa durée de vie.

Aucun défragmenteur sérieux ne proposerait de défragmenter un SSD.

Windows détecte très bien les SSD et la seule optimisation qu'il fait alors est d'envoyer un ReTRIM au SSD pour lui dire qu'il faut remettre à zéro les cellules effacées, si ce n'est pas déjà fait.

Si tu n'es pas convaincu, c'est toi qui paye.

Je n'utilise que Défrag, mais je n'ai jamais eu de soucis pour le supprimer totalement !!

Tu n'as pas besoin de supprimer defrag si tu as des HDD. Au contraire.

Juste ne jamais défragmenter un SSD.

Daneel Olivaw a écrit :

Tu n'as pas besoin de supprimer defrag si tu as des HDD. Au contraire.

Juste ne jamais défragmenter un SSD.

Je ne dis pas que je veux l'enlever, je te répond au fait que tu dis que les produits O&O sont difficiles à "éradiquer". Alors, ... vraie rumeur ou fausse info ....😉

Je te parle de mon expérience personnelle. Ils ont tendance à s'incruster. Et leurs logiciels payant ne font pas mieux que les gratuits.

https://www.oo-software.com/en/products/oodefrag

Celui qui a écrit ça n'aucune idée de la manière dont fonctionne un SSD.

https://www.tomshardware.fr/articles/ssd-flash-disques,2-393-5.html

Et il veut réduire l'usure en défragmentant alors que le simple fait de déplacer inutilement les blocs augmentent le nombre d'écritures et donc l'usure. Paradoxal.

Le SSD travaille comme la RAM. La fragmentation n'aucune influence sur la rapidité.

tous les SSD n'ont-ils pas un logiciel d'optimisation dédié ?

Je n'ai que des Samsung Evo et ils sont livrés avec un logiciel. Dans ce logiciel, il y a un menu d'optimisation.

Salut,

Un SSD est de la mémoire. Que cette mémoire soit fragmentée ou pas, sa vitesse d'accès restera la même (sauf pour quelques éditeurs de logiciels bidons qui prétendent le contraire).
Au mieux, tu gagneras quelques ns (nano secondes, milliardièmes de secondes). Defrag ou pas, tu ne verras absolument aucune différence.

A toi de voir, si tu es prêt à flinguer plus rapidement un disque dans l'hypothétique espoir de grappiller quelques milliardièmes de secondes, vas-y !

De plus, comme déjà dit, ce que te dit Windows sur la fragmentation du disque ne représente pas la réalité. Windows ne sait pas où sont les données sur le disque (ça s'appelle le nivellement de l'usure et Windows n'a aucun contrôle là dessus).

Est-ce que tu défragmentes tes clés USB ? Pourtant le principe est le même, les SSD sont des clés USB géantes... (enfin presque, en plus sophistiqué)

Super_GEGE a écrit :

tous les SSD n'ont-ils pas un logiciel d'optimisation dédié ?

Je n'ai que des Samsung Evo et ils sont livrés avec un logiciel. Dans ce logiciel, il y a un menu d'optimisation.

il doit permettre le réalignement du SSD ce qui est un peu le pendand de la défragmentation.

Bonsoir

Merci Daniel pour ces explications très détaillées.

Puisque l'on est dans le sujet du SSD. Je commence à regarder de ce côté là pour mon disque système (occupé à 96 Go). Un 128 me plaîrait assez.

Y-a-t'il des marques de SSD meilleures que d'autres ?

Qu'est-ce qui fait la différence entre un SSD de chez Tartampion et un autre de chez Crucial ou Kingston ou même Samsung puisque la base du produit est la même ?

Les fameux MLC, TLC, SLC ?

pétard77 a écrit :

Bonsoir

Merci Daniel pour ces explications très détaillées.

Puisque l'on est dans le sujet du SSD. Je commence à regarder de ce côté là pour mon disque système (occupé à 96 Go). Un 128 me plaîrait assez.

Y-a-t'il des marques de SSD meilleures que d'autres ?

Qu'est-ce qui fait la différence entre un SSD de chez Tartampion et un autre de chez Crucial ou Kingston ou même Samsung puisque la base du produit est la même ?

Les fameux MLC, TLC, SLC ?

La différence entre Tartampion et Crucial ou Kingston, c'est la qualité de la mémoire flash et celle du contrôleur intégré, donc aussi la manière dont est gérée la flash.

La mémoire flash est lente, et pour l'accélérer, on met plusieurs puces en parrallèle. Plus la capacité d'un SSD est élévée, plus il y a de puces qu'on peut mettre en parallèle. C'est pourquoi les SSD de 64 GO et 128 GO sont plus lents qu'un SSDD de 256 ou 512.

Et plus la capacité est élevée plus il y a d'espace pour écrire et donc étaler l'usure èt augmenter l'endurance.

Quand on fabrique une puce quelconque, que ce soit un processeur, une RAM ou une mémoire flash, les puces sont triées selon la qualité de la gravure. Les meilleures sont vendues comme premier choix, celles un peu moins bien, deuxième choix etc...

On ne fabrique pas des RAM à 2333 et des RAM à 2600. On fabrique de la meilleur façon possible. Celles qui passent le test 2600 sont estampillées 2600, celles qui passent le test 2333 sont estampillées 2333, etc... les restes sont vendues à des fabricants noname.

Pour aider à choisir un SSD :

https://www.lesnumeriques.com/ssd/comparatif-ssd-a1632.html

https://www.tomshardware.fr/articles/test-comparatif-disques-ssd,2-3.html

Bonjour

Très enrichissant. Merci.

Gazby a écrit :

.......

Traduction
En outre, l'usure prématurée du disque SSD (et bien sûr du disque dur conventionnel) est évitée, car moins de blocs doivent être effacés et réécrits qu'avant la défragmentation avec SOLID.

Il écrivent que l'usure prématurée est évité car moins de blocs doivent êtres réécrits. Ils avouent donc que l'écriture use le SSD.
Ce qui est moins honnête de leur part c'est que le peu qui est réécrit suffit quand même à diminuer la durée de vie du disque pour un résultat dont ils ne disent pas qu'il n'est pas quantifiable en regard de la vitesse à laquelle la mémoire est accédée. Pour exprimer ceci d'une manière plus compréhensible disons qu'on ne se rendra pas compte du gain de temps que la défragmentation aura apportée.
Il faut avouer que le SSD fait sûrement le désespoir des programmeurs spécialisés depuis longtemps dans ces applications pour disque. Leurs commerciaux doivent aussi essayer de conserver leur boulot !

Mais même un disque normal vieillit quand on abuse de la défragmentation. Le déplacement incessant de la tête qui est un organe mécanique précipite le futur disfonctionnement du disque.
.............

Donc pour résumer il faut faire attention à ce qu'on fait avec un SSD mais aussi avec un disque classique.

...........

Je suis entièrement d'accord avec toi sur le fait que d'une part l'accélération promise doit être tellement faible qu'elle est probablement "in-mesurable" pour l’utilisateur Lambda, tout comme je suis bien conscient que O&O essaye de ménager son avenir en se positionnant de cette manière sur le marché du SSD qui prend graduellement la place de celui du HDD.

Ceci étant, prenons l'hypothèse qu'il disent vrai concernant leur technologie SOLID. Ils ont quand même démontré depuis toutes ces dernières années leur compétence en matière de défragmentation des HDD et sont considérés comme les plus performants dans ce domaine (après, on pourra toujours discuter du bien fondé de la défragmentation mais c'est un autre débat).

Donc, on admet que leur technologie SOLID fonctionne et que "moins de blocs doivent être effacés et réécrits qu'avant la défragmentation avec SOLID."
Comme les écritures usent le disque, ce qu'eux même admettent implicitement, ... moins d'écritures diminuent donc l’usure du SSD, ... donc SOLID diminue l'usure du SSD. Postulat simple et logique.
On peut leur faire un procès sur les intentions mercantiles cachées de leur exposé (... quoique, ... on crée rarement une société à but uniquement philanthropique ...), mais le postulat reste vrai quoiqu'il en soit.

Conclusion :

Peut-on leur accorder quand même un minimum de crédibilité : oui. Peut-on pour autant se lancer à corps perdu dans la défragmentation des SSD : non.
De toute façon, je pense qu'aujourd'hui, les SSD doivent rester des supports d'enregistrement pour les OS et les programmes, et il est encore largement préférable de déplacer les fichiers tampons, les fichiers temporaires et l'ensemble des fichiers finaux sur des HDD classiques. Dans ce cas, les SSD ne gagnent quasiment rien à être défragmentés.

Doit-on défragmenter systématiquement les disques : c'est le débat qui reste à entamer. Si on applique cette même technologie (défragmenter et réécrire les fichiers très peu souvent modifiés), on peut penser que oui.

EDIT quelques heures plus tard .... : je me rends compte que ce que je disais plus haut ne fait pas forcément sens : si un fichier n'est pas modifié, il n'a pas besoin non plus d'être réécrit juste pour le défragmenter. Celà ne changera rien, sauf qu'il aura étré réécrit ... Il y a quelque chose dans l'exposé fait par O&O qui m'échappe ...

Gazby a écrit :

Bonjour, ....

, voir --> https://forum.pcastuces.com/optimiser_windows_7_pour_son_ssd-f12s691.htm

remarque:

Gazby a écrit :

Bonjour,

Gallagh quand tu écris que le SSD peut servir à stocker le système d'exploitation il ne faut pas oublier que Windows utilise des fichiers temporaires et que le système écrit constamment dans des petits fichiers.
Si de plus on a le fichier de mémoire paginé sur ce disque il est quand même forcément très sollicité à moins d'avoir beaucoup de mémoire vive qui elle ne s'use pas.

L'idéal serait de stocker sur le SSD ce qui doit être lu rapidement comme les programmes et le système d'exploitation mais en déplaçant tout ce qui est constamment accédé sur un disque classique.

Mais je pense que la plupart des utilisateurs ne font pas ça. En ce qui me conserve je conserve les disques classique qui apportent une bien plus grande capacité même s'ils sont un peu plus lent mais tout ça c'est une affaire de goût et chacun fait ce qu'il lui plaît.

A+ Gazby.

Désolé Gazby, tu n'as pas bien lu ce que j'ai écrit ..... Ai-je dis le contraire ? J'ai même supprimé les fichiers Prefetch.

Gazby a écrit :

Bonjour,

Gallagh quand tu écris que le SSD peut servir à stocker le système d'exploitation il ne faut pas oublier que Windows utilise des fichiers temporaires et que le système écrit constamment dans des petits fichiers.
Si de plus on a le fichier de mémoire paginé sur ce disque il est quand même forcément très sollicité à moins d'avoir beaucoup de mémoire vive qui elle ne s'use pas.

L'idéal serait de stocker sur le SSD ce qui doit être lu rapidement comme les programmes et le système d'exploitation mais en déplaçant tout ce qui est constamment accédé sur un disque classique.

Mais je pense que la plupart des utilisateurs ne font pas ça. En ce qui me conserve je conserve les disques classique qui apportent une bien plus grande capacité même s'ils sont un peu plus lent mais tout ça c'est une affaire de goût et chacun fait ce qu'il lui plaît.

A+ Gazby.

Déjà il y a SSD et SSD, plusieurs technologies, gestions, rapidité, types de mémoire, etc...

Beaucoup ont acheté des PC portables avec SSD depuis 7-8 ans et fonctionnent sans problème encore aujourd'hui !

Maintenant, certaines marques annonces des SSD encore beaucoup mieux qu'il y a 7-8 ans, alors je pense qu'on spécule beaucoup pour rien !

Si on est sérieux, on fait une image de son DD ou SSD et au cas où, on en achète un neuf pour restaurer l'image dessus pour repartir pour plusieurs années encore.

Bonsoir,

Questions subsidiaires .....

- Importance du trim ?

- Le trim avec Linux ?

Gallagh a écrit :

Bonsoir,

Questions subsidiaires .....

- Importance du trim ?

- Le trim avec Linux ?

Le TRIM est indispensable. On ne peut écrire une celleule flash que si tous les bits sont à zéro. Quand l'OS supprime un fichier, il envoie la commande TRIM au SSD pour lui spécifier de remettre à zéro les cellules considérées.

Sans TRIM, le SSD deviendrait très lent dès que toutes les celllules ont été utilisées une fois. C'était le cas des premiers SSD.

Linux supporte sans problème le TRIM.

Toutes les distros Linux ?

Je dois préparer un vieux PC en le passant sur Linux et avec un SSD ....

Gallagh a écrit :

Toutes les distros Linux ?
Oui, à moins que ce ne soit une distro datant de Mathusalem.

Je dois préparer un vieux PC en le passant sur Linux et avec un SSD ....
Pour que le TRIM fonctionne, il faut être en AHCI. Sinon, pas de TRIM.

Daneel Olivaw a écrit :

Gallagh a écrit :

Bonsoir,

Questions subsidiaires .....

- Importance du trim ?

- Le trim avec Linux ?

Le TRIM est indispensable. On ne peut écrire une celleule flash que si tous les bits sont à zéro. Quand l'OS supprime un fichier, il envoie la commande TRIM au SSD pour lui spécifier de remettre à zéro les cellules considérées.

Sans TRIM, le SSD deviendrait très lent dès que toutes les celllules ont été utilisées une fois. C'était le cas des premiers SSD.

Linux supporte sans problème le TRIM.

Mais je ne comprends pas comment ou pourquoi il faut remettre les "bits" à zéro ?

Il n'est pas censé savoir qu'un fichier a été supprimé ou a été déplacé ?

Cela veut-il dire aussi, alors, qu'un SDD non trimmé afficherait de mauvaises informations concernant l'espace disponible ?

Le logiciel que j'utilise sous Windows XP pour trimmer mon SSD, écrit des fichiers d'environ 3Go jusqu'à ce qu'il n'y ait plus de place et une fois plein, il est indique que c'est terminé.

Si ce que tu dis est vrai, alors "Eraser" qui remet à zero les espaces vides, ferait pareil ?

regedice a écrit :

Mais je ne comprends pas comment ou pourquoi il faut remettre les "bits" à zéro ?
Parce que la technologie de la mémoire flash est comme ça. La flash est une mémoire série, contrairement à la RAM qui est parallèlle.
On ne peut écrire (et effacer) qu'un bloc entier (128 ou 256 KO), même s'il n'y a qu'un bit à modifier, et il faut alors réecrire le bloc ailleurs et mettre l'ancien à zéro.

Il n'est pas censé savoir qu'un fichier a été supprimé ou a été déplacé ?
Non, de même qu'un HDD ne le sait pas non plus. C'est la MFT qui conserve les emplachements des fichiers.
Sur un disque quelconque, HDD ou SSD, la MFT gère les fichiers. Quand tu écris un fichier, la MFT ($MFT)écrit dans un de ses blocs le nom, date, permissions etc ET les secteur occupés par ce fichier, ainsi que dans un autre fichier de la MFT ($Bitmap), il marque quels sont les secteurs occupés et ceux qui sont libres. Ainsi quand Windows cherche un secteur libre pour écrire un nouveau fichier, il n'a qu'à lire le fichier $Bitmap.
Quand tu effaces un fichier, le bloc de la MFT indique qu'il a été supprimé, les numéros secteurs occupés ont été supprimés et les secteur marqués Occupés par le fichier dans le fichier $Bitmap sont remis comme étant libres. Mais rien n'est supprimé physiquement sur le disque. On peut récupérer le fichier avec des logiciels de récupération.

Sur un SSD, c'est exactement pareils, Mais, car il y a un mais, on ne peut pas écrire sur un secteur si tous les bits ne sont pas à zéro. On peut le faire au moment d'écrire le fichier, mais cela ralentirait énormément le SSD.
C'est là qu'intervient la fonction TRIM. Dès que l'OS supprime un fichier, il envoie la commande TRIM au SSD pour lui dire de remettre les bits à zéro. Cela se fait de manière transparente, à un moment ou on n'est pas en train d'écrire, donc sans ralentissement.

Autree précision : Un OS, quel qu'il soit, ne sait pas du tout sur quels blocs du SSD sont enregistrés les données, à cause de la gestion de l'usure. Le SSD déplace à son gré les données pour répartir l'usure sur tous les blocs. La MFT pointe en fait sur des blocs virtuels. Quans Windows demande un secteur quelconque, le contrôleur du SSD cherche dans sa propre table quel bloc physique correspond au secteur demandé par Windows.

Cela veut-il dire aussi, alors, qu'un SDD non trimmé afficherait de mauvaises informations concernant l'espace disponible ?
Non, pas de mauvaises informations, simplement un ralentissement, parce qu'il faut d'abord effacer avant d'écrire.

Le logiciel que j'utilise sous Windows XP pour trimmer mon SSD, écrit des fichiers d'environ 3Go jusqu'à ce qu'il n'y ait plus de place et une fois plein, il est indique que c'est terminé.
XP ne supporte pas le TRIM, alors il faut recourir à des artifices. Chaque fabricant de SSD a sa méthode.

Si ce que tu dis est vrai, alors "Eraser" qui remet à zero les espaces vides, ferait pareil ?
Eraser n'est pas fait pour le TRIM, il est fait pour la sécurité des données, et je ne pense pas qu'il ait une utilité quelconque sur un SSD.
Parce qu'il ne peut pas faire pareil.
Sur un HDD tu sais sur quels secteurs sont écrit le fichier et tu les mets à zéro. Facile.
Sur un SSD, tu ne sait pas sur quels blocs est situé le fichier. L'écraser par des zéro va provoquer sa réécriture sur un autre bloc avec des zéros, et les blocs actuels seront remis à zéro par le TRIM. S'il n'y a pas de TRIM, il resteront tels quels.
De toute façons, sur un SSD le TRIM va remettre à zéro les bits du fichier automatiquement après quelques secondes. C'est pourquoi on ne peut pas récupérer un fichier effacé sur un SSD avec TRIM.

Bonjour Daneel

Respect.

Cela reste quand-même très surprenant !

Tu parles de 128 ou 256Ko c'est beaucoup ! On parlait de 512 Octets et désormais 4Ko, mais là on créerait des blocs de 128 ou 256Ko minimum ?

Mais pourquoi le trimm, le fait de dire au SSD qu'il doit effacer alors qu'il est censé, lui, gérer le stockage des données de manière à les répartir ?

Cela me rappelle la manière d'écrire une punition, comme écrire 500x une lignes sur des feuilles de papier, il y avait ceux qui écrivait chaque ligne en entier, alors que d'autres écrivaient 500x "je", puis 500x "ne", puis 500x "ferait"...

Donc qu'on écrive sur une case et encore et encore jusqu'à ce qu'elle meurt ou qu'on écrive un peu partout en comptant le nombre de fois jusqu'à ce qu'elles meurent toutes les unes après les autres, qu'est-ce que ça change ?

Et si on donne l'ordre de suppression d'un fichier, le SSD va indiquer dans son registre qu'il a supprimé les datas contenus dans les casiers X12, X13, X14, etc... Pourquoi quand il reçoit l'info, il ne va pas lui-même vider les données ou remettre les casiers mémoires à zero par une impulsion électrique ?

Je ne comprends vraiment pas le fonctionnement de cette nouvelle technologie qui compte sur des ordres envoyés d'un OS pour faire le job qu'elle devrait faire d'elle-même !?

Gazby a écrit :

Bonjour,

Daneel Olivaw ton explication est très intéressante. Si j'ai bien compris finalement quand on efface des fichiers sensibles sur un SSD, personne ne pourra ensuite les récupérer après le passage de la commande Trim. Est-ce bien ça ?

danee merci d'avoir communiqué le lien rappelant la manière d'optimiser le fonctionnement d'un SSD.

A+ Gazby.

Oui, c'est tout à fait ça.

regedice a écrit :

Cela reste quand-même très surprenant !

Tu parles de 128 ou 256Ko c'est beaucoup ! On parlait de 512 Octets et désormais 4Ko, mais là on créerait des blocs de 128 ou 256Ko minimum ?
512 Octets et 4 KO c'est les HDD. La mémoire flash travaille différemment. J'ai expliqué avant. Certe, on peut faire de la flash avec des blocs plus petits, comme on peut faire des HDD avec des secteurs de 1 octet. Mais il faut choisir un compromis entre fiabilité, vitesse, gestion de l'usure, correction d'erreur, capacité etc, qui donne un disque rapide et sûr.
Sur un HDD, on est passé aux secteurs 4 KO principalement pour augmenter la densité par plateau.
L'Advanced Format, le nom officiel de la technologie, a le gros avantage de permettre de stocker plus de données sur la même surface. Expliquons. Un secteur de 512 octets nécessite en réalité plus d'espace physique : il y a 512 octets de données, 15 octets qui servent à la synchronisation des secteurs et 50 octets pour la correction d'erreur (le code ECC, qui a une efficacité dans ce cas précis de 88 %). Dans le cas où l'on doit écrire 4 ko, il y a donc 515 octets écrits en plus des données utilisables.
En format 4 ko, les données de synchronisation restent identiques (15 octets) mais l'ECC passe à 100 octets (pour 4 ko de données). Cette modification permet d'améliorer la correction d'erreur (qui passe à 97 % d'efficacité) tout en limitant au final l'espace disque utilisé : on se retrouve avec seulement 115 octets supplémentaires et la différence permet donc d'augmenter la capacité utilisable des disques durs.
https://www.tomshardware.fr/articles/secteur-advanced-format,1-1993.html

Mais pourquoi le trimm, le fait de dire au SSD qu'il doit effacer alors qu'il est censé, lui, gérer le stockage des données de manière à les répartir ?
Le TRIM n'efface pas. Le fichier a été effacé par l'OS. Le TRIM prépare la place pour le fichier suivant en remettant à zéro les cellules.
Quand tu prends l'avion, tu descends à l'arrivée, donc la compagnie d'aviation t'a effacé. L'équipe de nettoyage arrive pour remettre les sièges à zéro, sans virus, microbes, bactéries etc pour les passagers suivants.

Cela me rappelle la manière d'écrire une punition, comme écrire 500x une lignes sur des feuilles de papier, il y avait ceux qui écrivait chaque ligne en entier, alors que d'autres écrivaient 500x "je", puis 500x "ne", puis 500x "ferait"...
Rien de comparable.

Donc qu'on écrive sur une case et encore et encore jusqu'à ce qu'elle meurt ou qu'on écrive un peu partout en comptant le nombre de fois jusqu'à ce qu'elles meurent toutes les unes après les autres, qu'est-ce que ça change ?
ca change que le SSD va diminuer rapidement de capacité au fur et à mesure que les cellules s'usent, puisque c'est toujours les mêmes cellules que tu va utiliser. Et l'usure sera exponentielle.

Et si on donne l'ordre de suppression d'un fichier, le SSD va indiquer dans son registre qu'il a supprimé les datas contenus dans les casiers X12, X13, X14, etc... Pourquoi quand il reçoit l'info, il ne va pas lui-même vider les données ou remettre les casiers mémoires à zero par une impulsion électrique ?
Sans doute optimisation des performance. Quand l'OS a fini d'écrire, il envoie alors la commande TRIM pour signifier au SSD qu'il peut faire le nettoyage.
Comme dans l'avion : Quand le dernier passager est descendu, on informe le service de nettoyage qu'il peut commencer.

Je ne comprends vraiment pas le fonctionnement de cette nouvelle technologie qui compte sur des ordres envoyés d'un OS pour faire le job qu'elle devrait faire d'elle-même !?
Plus clair que ça on ne peut pas.

voilà un fil de message digne d'intérêt.

Merci aux intervenants avec mention spéciale à certains ....

Daneel Olivaw a écrit :

regedice a écrit : Donc qu'on écrive sur une case et encore et encore jusqu'à ce qu'elle meurt ou qu'on écrive un peu partout en comptant le nombre de fois jusqu'à ce qu'elles meurent toutes les unes après les autres, qu'est-ce que ça change ?

ca change que le SSD va diminuer rapidement de capacité au fur et à mesure que les cellules s'usent, puisque c'est toujours les mêmes cellules que tu va utiliser. Et l'usure sera exponentielle.

Tu veux dire que plus une cellule est utilisée, plus rapidement elle s'approche de la mort ?

Du genre: de 1 à 100 écriture = une écriture vaut 1, de 101à 500 = une écriture vaut 1.5, de 501 à 1000 = une écriture vaut 2, et ainsi de suite ?

Et si on donne l'ordre de suppression d'un fichier, le SSD va indiquer dans son registre qu'il a supprimé les datas contenus dans les casiers X12, X13, X14, etc... Pourquoi quand il reçoit l'info, il ne va pas lui-même vider les données ou remettre les casiers mémoires à zero par une impulsion électrique ?

Sans doute optimisation des performance. Quand l'OS a fini d'écrire, il envoie alors la commande TRIM pour signifier au SSD qu'il peut faire le nettoyage.
Comme dans l'avion : Quand le dernier passager est descendu, on informe le service de nettoyage qu'il peut commencer.

Oui j'ai bien compris, mais pourquoi n'est-ce pas fait directement par le SSD lui-même lorsque l'opération est finalisée ? Ce qui est encore plus étrange, c'est que l'OS, vu qu'il a demandé de ré-écrire l'index en supprimant une partie de son contenu, ne peut plus savoir où sont les données effacées. Donc le Trim est un ordre donné du genre: "vide toutes les cellules qui sont censées ne rien contenir" et visiblement, le contrôleur du SSD, lui, sait quelles sont les cellules contenant les données supprimées du registre des cellules qui sont vides.

Je ne comprends vraiment pas le fonctionnement de cette nouvelle technologie qui compte sur des ordres envoyés d'un OS pour faire le job qu'elle devrait faire d'elle-même !?

Plus clair que ça on ne peut pas.

Je suis désolé, mais je pense qu'il y a une partie d'incohérence...

Car tu as expliqué que lorsque l'OS envoie l'ordre d'écriture, ce qui est écrit est indiqué dans l'index du disque (MFT/MBR/Etc...), mais qu'en même temps, les données peuvent se trouver ailleurs, étant donné que c'est le contrôleur du SDD qui gère le stockage et le "placement" des données en fonction de l'usure des cellules ?

Alors pourquoi, quand le contrôleur va aller écrire l'index pour lequel il aura reçu l'ordre de supprimer des données de la liste, en même temps, il ne libère pas ces cellules ?

C'est comme si on avait créer un programmation incomplète des commandes !

Puisqu'il faut vider les cellules avant d'écrire dedans, il est évident que si on supprime le contenu de ces cellules, dans l'index, on doit aussi remettre à zéro les cellules qui stockaient ces données.

Ca me fait penser au formatage rapide et complet, on indique au DD par l'ordre du formatage rapide, de nettoyer l'index de ses écritures, alors que les datas se trouveront toujours sur la surface du disque, il n'y a que le formatage complet qui va remettre à zéro chaque cluster.

Donc là, à chaque suppression, un SDD doit recevoir l'ordre en même temps, de vider ou de remettre à zéro les cellules.

Est-ce que le fait de trimer une cellule compte comme une écriture ?

Tu veux dire que plus une cellule est utilisée, plus rapidement elle s'approche de la mort ?
Du genre: de 1 à 100 écriture = une écriture vaut 1, de 101à 500 = une écriture vaut 1.5, de 501 à 1000 = une écriture vaut 2, et ainsi de suite ?

Non. Une cellule a un nombre d'écritures limité et connu. Par exemple 500 pour un TLC.
Sans gestion d'usure, tu vas écrire souvent dans la même cellule. Windows écrit entre 2 et 5 GO par jours. 500 écritures sont très rapidement atteints quand c'est toujours au même endroit et la cellule va défuncter rapidement. Tu vas voir la capacité de ton SSD se réduire chaque jour.
L'explication est dans cette page sur le lien que j'ai déjà donné.
https://www.tomshardware.fr/articles/ssd-flash-disques,2-393-5.html

Oui j'ai bien compris, mais pourquoi n'est-ce pas fait directement par le SSD lui-même lorsque l'opération est finalisée ? Ce qui est encore plus étrange, c'est que l'OS, vu qu'il a demandé de ré-écrire l'index en supprimant une partie de son contenu, ne peut plus savoir où sont les données effacées. Donc le Trim est un ordre donné du genre: "vide toutes les cellules qui sont censées ne rien contenir" et visiblement, le contrôleur du SSD, lui, sait quelles sont les cellules contenant les données supprimées du registre des cellules qui sont vides.

Si tu lisais les liens que je donne, tu aurais trouvé la réponse :
https://www.tomshardware.fr/articles/ssd-flash-disques,2-393-8.html