Comme vous le savez, les SSD sont de plus en plus courants et Windows 7, le prochain OS de Microsoft, sera optimisé pour ce type de support de stockage. Sur un blog dédié à Windows 7, Microsoft explique quelques-unes des optimisations de son système pour les SSD.
Quelques optimisations désactivées
Avec un SSD (pour peu que le système le reconnaisse comme tel), Windows 7 désactive certaines optimisations. Vous ne comprenez pas ? C'est normal, les optimisations en question sont destinées aux disques durs et à leurs plateaux en rotation, chose que les SSD ne possèdent pas. Dans les faits, le SuperFetch (un préchargement des données souvent utilisées) et le ReadyBoost (l'utilisation de mémoire flash pour réduire l'accès à la lecture de certaines données) sont désactivés parce qu'ils sont inutiles sur un SSD. De plus, la défragmentation automatique est supprimée parce qu'elle ne sert à rien (étant donné la façon dont sont écrites sur les SSD et l'absence de temps de latence variable) et la création de partition est effectuée de façon efficace, avec un alignement sur les blocs de la mémoire flash (ce que ne fait pas Windows XP).
Enfin, le support du TRIM — une technique qui permet de déléguer une partie de la gestion de l'usure au système d'exploitation — est bien implémenté (dans la RC) mais nécessite évidemment un SSD équipé d'un firmware compatible, ce qui n'existe pas actuellement. Selon Microsoft, le système de fichier NTFS a été adapté et les outils qui écrivent sur les supports (format, delete, etc.) sont compatibles avec la norme. Pour le moment, seul OCZ propose un support du TRIM, mais avec un utilitaire externe, alors que des rumeurs indiquent qu'Intel, notamment, devrait proposer un firmware compatible dès la sortie de la version finale de Windows 7.
Au final, on se rend compte que Microsoft adapte son OS aux nouvelles technologies et que même si les SSD sont proches des disques durs dans le comportement logique, ils restent assez différents en utilisation au quotidien.
Alors pourquoi faire un distinguo entre "lecture séquentiel" et "lecture aléatoire", dans les bench de SSD ?
Parce que ça ne dépend pas du temps d'accès en lui-même et que défragmenter n'a aucun impact sur les perfs en aléatoire, qui dépendent de la technologie en elle-même.
pas de doutes à avoir
-le temps d'accès est constant, donc la fragmentation n'a pas d'effet
-la structure même des SSD fait que même si c'est rangé au niveau logique, ça l'est pas au niveau physique, donc défragmenter, ça sert juste à mélanger d'une autre façon, c'est tout.
non, l'exFAT c'est pour les perifs externes, pas pour le système ou NTFS est bien plus fiable/complet
Non, justement, les débits en accès aléatoire que ce soit pour les SSD ou les HDD sont largement inférieurs à ceux obtenus en accès séquentiel.
Un fichier fragmenté, c'est des blocs inscrit un peu n'importe où sur le volume. Si mon fichier est fragmenté à 100%, ça signifie qu'aucun bloc n'est juxtaposé avec un ses voisins logiques, donc la lecture dudit fichier reviendra à faire des accès aléatoires dont on sait que ça nuit au performance du ssd.
A contrario un fichier non fragmenté revient à ne faire que des accès séquentiels, et là on atteint le débit maximal (bench à l'appui, pourquoi j'en sais rien).
Donc où est l'erreur dans mon raisonnement ?
Un fichier fragmenté, c'est des blocs inscrit un peu n'importe où sur le volume. Si mon fichier est fragmenté à 100%, ça signifie qu'aucun bloc n'est juxtaposé avec un ses voisins logiques, donc la lecture dudit fichier reviendra à faire des accès aléatoires dont on sait que ça nuit au performance du ssd.
A contrario un fichier non fragmenté revient à ne faire que des accès séquentiels, et là on atteint le débit maximal (bench à l'appui, pourquoi j'en sais rien).
Donc où est l'erreur dans mon raisonnement ?
les acces aléatoires, ca ne nuit pas en tant que tel, le temps d'accès est constant. Et comme dit plus haut, le volume, défragmenté ou pas au niveau logique (du FS), il est fragmenté en interne : un SSD, par nature, est fragmenté, c'est pas un problème.
Globalement, c'est le fonctionnement en bloc qui pose des problèmes : on lit par page, on écrit par bloc (4 Ko/128 Ko, parfois le double). Le temps de lecture/écriture est constant quel que soit la taille du fichier (donc 1 octet ou 2 Ko, ça prend le même temps). Donc en acces aléatoire de fichiers de 4 ko, on perd en perfs, oui, surtout en écriture, vu qu'on écrit 128 Ko réel pour 4 Ko logique, et qu'on recommence. En séquentiel, on écrit 128 Ko réle pour 128 Ko pratique. Et en ecriture, y a le problème du wear-levelling ralentit un peu, pour le choix de la bonne cellule.
oui exact.
Dès qu'on aura inventé les bits élastiques...
Dès qu'on aura inventé les bits élastiques...
ca c est de l esprit !!!
oui