[VotreAvis] Ordinateur lent depuis peu

On ne défragmente JAMAIS un SSD et aucun logiciel sérieux ne propose de le faire. Le défragmenteur de Windows depuis W7 ne le fait jamais, il n'utilise que la commande TRIM sur ces supports, la seule chose qu'on doit faire sur un SSD.

Il est non seulement inutile et néfaste mais surtout impossible techniquement de défragmenter un SSD. Les données sont toujours volontairement fragmentées par nécessité de répartir l'usure des blocs et aucun logiciel ne peut changer cela, car aucun logiciel, pas même l'OS, ne sait comment sont agencés et gérés les blocs physiques. Seul le contrôleur du disque le sait. Le logiciel de défrag va demander à accéder au bloc 546 par exemple, mais ce sera en réalité le 6424 qui sera traité (ou le 3692 une autre fois, puisque le contrôleur opère des rotations de blocs), sans qu'il n'ait le moindre moyen de le savoir. La jolie représentation graphique de ces logiciels ne reflète donc en rien la réalité du support lorsqu'il s'agit d'un SSD, c'est juste la représentation de la table d'allocation qui est dans le cas d'un SSD purement virtuelle.

Défragmenter un SSD n'engendre que des écritures inutiles et donc de l'usure (puisque chaque cellule a une durée de vie en nombre d'écritures), sans rien défragmenter du tout (car c'est le contrôleur qui décide de l'organisation du support physique et lui seul). Même si c'était possible ça n'aurait strictement aucun intérêt, accéder à n'importe quel bloc mémoire demande le même temps où qu'il soit situé, exactement comme de la RAM et contrairement à ce qui se passe avec un disque mécanique qui doit déplacer plus ou moins longuement sa tête de lecture d'un cylindre à l'autre.

La commande TRIM par contre est très importante pour faire le lien entre la réalité physique du support (gérée par le contrôleur et connue par lui seul) et l'OS (le système de fichier), permettant au SSD d'optimiser sa gestion de l'usure en fonction de l'usage du disque (le contrôleur ne sait pas quel bloc est utilisé ou non par le système de fichier, de même que le système de fichier ignore tout de l'organisation physique du support). Cette commande améliore les performances et prolonge la durée de vie du support, permettant au contrôleur de mieux répartir les données sur les cellules les moins utilisées.

Voici un article simple sur le fonctionnement des mémoires flash (les autres pages aussi sont intéressantes) :

Les disques SSD, la fin des disques durs - Page 5 sur 11

Et enfin un autre article qui explique simplement pourquoi on ne doit pas défragmenter un SSD :

Sept idées reçues sur les SSD : vrai ou faux ? - Page 5 sur 8

 

Article de 2014 !, les SSD ont bien évolué depuis.

Relis ce que j'ai écrit, je ne parle pas de la position des cluster, mais de la fragmentation qui génère des accès inutiles à la MFT

Olivier

 

Si on considère ceci comme vrai

Et ceci aussi

Quelle est la nouveauté qui justifierait de défragmenter un disque SSD...

Juste pour comprendre...

 

L'article est toujours valable, c'est toujours comme ça que fonctionne la mémoire flash, ce sont surtout les algorithmes des contrôleurs qui évoluent pour répartir le plus efficacement possible l'usure sur toutes les cellules (en "fragmentant" au maximum les données sur la mémoire).

La table d'allocation n'est qu'une représentation virtuelle sur ces supports. Ce que certains avancent (à tort !) c'est un problème de conception du NTFS qui utilise plusieurs tables, cela générant de la "fragmentation". Déjà, on est en 2020, mes SSD de données sont formatés en ReFS. Ensuite, même en NTFS, qu'il faille lire 4 tables ou 1 seule, vu les temps d'accès de quelques nanosecondes pour lire un bloc, c'est parfaitement négligeable. Ça ne vaut pas la chandelle d'user des cellules en faisant un défrag qui va n'affecter que la MFT en réalité, juste pour espérer gagner quelques nanosecondes.

 

Ok....je comprend mieux les arguments...

Il y a t-il une taille de cluster recommandée quand on travaille en photo-video ( jouant un rôle dans la performance ? Ou longévité ? ) ?

 

La taille des blocs physiques (appelés pages puisque c'est de la mémoire paginée ou blocs) est fixe sur un SSD, généralement de 4096 octets (4K). Si tu changes la taille des clusters, ça n'a évidemment aucun impact sur cette taille physique. Cela joue par contre sur le nombre de tables d'allocations que va utiliser un système de fichiers comme FAT ou NTFS. Si tu écris très majoritairement des gros fichiers, une taille de cluster plus importante sera globalement plus efficace.

Un exemple : si la taille des clusters est de 4K (la valeur standard), et que tu enregistres un fichier de 1Go, il faudra beaucoup de blocs (clusters) de 4K et donc aussi beaucoup de tables d'allocations chaînées pour le stocker (parce-qu'une table d'allocation, qui liste les clusters utilisés par un fichier, a un nombre d'entrées limitées). Si ton cluster fait 64K, il faudra 16x moins de clusters et donc moins de tables pour stocker le fichier, ce sera plus efficace et ça usera moins le support car moins de blocs seront écrits. Mais dans ce cas, le moindre petit fichier de quelques octets sera pénalisant car il prendra systématiquement 64K, et usera autant de cellules correspondantes. Un SSD ne sait pas quelles données sont utiles ou non (de même qu'il ignore tout du concept de "fichier"), même un fichier rempli de 0 génère des écritures et donc de l'usure. C'est donc un compromis à faire.

Sur les systèmes de fichier modernes (comme ReFS par exemple sous Windows depuis la 8.1 je crois), ce questionnement n'a plus lieu d'être car le fonctionnement est très différent des anciens systèmes comme FAT ou NTFS. C'est similaire à la gestion d'une base de données, il n'y a pas les limites inhérentes à un système basé sur des tables d'allocation (il n'y a pas de MFT en ReFS).

Tous mes SSD sous Windows, hormis celui de boot car ce n'est pas possible, sont formatés en ReFS avec des clusters de 4K ou 64K (les deux seules possibilités en ReFS). 64K pour les deux SSD de rushes car je ne stocke QUE ça dessus et que ce sont de très gros fichiers, 4K sur tous les autres SSD plus généralistes. Microsoft ne recommande pas d'utiliser des clusters de 64K en ReFS sauf cas particuliers (les gros rushs en vidéo en sont un).

Toutes les personnes qui sont sous Windows 8.1 et supérieur devraient formater leurs disques de données en ReFS, qui est plus efficace que le NTFS. Sous W7 cependant il n'y a pas le choix.

 

Intéressant ....

Le ReFS est compatible avec tout système ?

 

Juste W8.1 et W10 Pro et Entreprise (et les versions Server de Windows depuis 2012). Donc non, un disque formaté en ReFS ne peut pas être utilisé sous un autre OS que ceux-là. C'est un système encore jeune, loin des possibilités offertes par des systèmes de fichiers du même type comme ZFS ou Btrfs, mais il a le mérite d'exister nativement sous Windows et de s'améliorer.

Le NTFS a donc encore de beaux jours devant lui, ne serait-ce que pour l'échange de données entre plusieurs OS.

 

Donc si je résume ce que j'ai compris : pas de défragmentation, pas ou peu d'effacement de données, mais dans le cas de SSD pour le montage, une fois le projet terminé, je fais un formatage de façon à avoir un disque propre pour le projet suivant.

 

Non, pas de défragmentation sur un SSD : c'est au mieux inutile et au pire néfaste (usure inutile).

On peut effacer des fichiers, c'est la table d'allocation qui sera modifiée, pas les blocs contenant effectivement les données, c'est donc une opération qui engendre très peu d'usure.

Oui, un formatage RAPIDE, juste pour remettre à zéro la table d'allocation des fichiers (donc très peu d'usure également). Et c'est prêt pour de nouveaux projets endiablés

 

Ouaou ! j'en apprends des choses !
Grand merci à vous tous