Se connecter avec
S'enregistrer | Connectez-vous

SSD et Windows 7 : Microsoft explique

Par - Source: Microsoft | B 19 commentaires

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.

Commentaires
Interroger un expert

Votre question aux experts de la catégorie Les news : vos réactions du forum

Exemple : Android, ordinateur portable, usb, disque dur

Cette page n'accepte plus de commentaires
  • efranchi , 13 mai 2009 18:47
    excellent article, thanks ;-)
  • lol51 , 13 mai 2009 19:19
    Citation :
    la défragmentation automatique est supprimée parce qu'elle ne sert à rien


    Alors pourquoi faire un distinguo entre "lecture séquentiel" et "lecture aléatoire", dans les bench de SSD ?
  • gobes , 13 mai 2009 19:32
    Pour prouver que c'est inutile?
  • Afficher les 19 commentaires.
  • dandu , 13 mai 2009 19:49
    gobesPour prouver que c'est inutile?


    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.
  • Outsider_42 , 13 mai 2009 22:21
    Euh, l'ex-FAT n'est il pas plus intéressant pour les SSD que le NTFS ?
  • dandu , 13 mai 2009 22:35
    Citation :
    Ca ne changera pas le fait que quand win aura installé les 100.000 applications du net, tout commencera à nouveau à ramer, ssd ou pas ... Puis, j'ai des doutes sur la fragmentation ... Donc, si j'étais superman, je pourrais éviter de ranger ma chambre tellement que je vais vite ..; Mouais, c'est pas très sexy tout ca quand meme ;) 


    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.

    Citation :
    Euh, l'ex-FAT n'est il pas plus intéressant pour les SSD que le NTFS ?


    non, l'exFAT c'est pour les perifs externes, pas pour le système ou NTFS est bien plus fiable/complet
  • -1 Masquer
    lol51 , 13 mai 2009 22:36
    gobesPour prouver que c'est inutile?


    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.
  • dandu , 13 mai 2009 22:48
    oui, mais c'est PAS lié à la fragmentation dans les SSD (et dans les disques durs, seulement en partie)
  • -3 Masquer
    lol51 , 13 mai 2009 22:59
    et c'est lié à quoi alors ?

    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 ?
  • Anonyme , 13 mai 2009 23:08
    C'est en effet une bonne nouvelle :) 
  • dandu , 13 mai 2009 23:30
    Citation :
    et c'est lié à quoi alors ?

    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.



  • lol51 , 13 mai 2009 23:49
    Dandules 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.
  • raioneru , 14 mai 2009 08:31
    bravo les gars, ca fait plaisir de voir des gens qui s'y connaissent :D  ;) 
  • -3 Masquer
    jay_rom , 14 mai 2009 09:04
    A quand les blocs qui se dimensionnent à la taille des données qu'ils contiennent ?
  • LVM , 14 mai 2009 11:13
    jay_romA quand les blocs qui se dimensionnent à la taille des données qu'ils contiennent ?


    Dès qu'on aura inventé les bits élastiques... :D 
  • wince , 14 mai 2009 15:02
    LVM -->>


    Dès qu'on aura inventé les bits élastiques... :D 

    ca c est de l esprit !!! ;) 
  • lologagny , 14 mai 2009 15:22
    ça existe... :) )
  • shooby , 14 mai 2009 19:02
    efranchiexcellent article, thanks ;-)

    oui