Inconvénients de la partition d'un SSD?
Un type sage qui s'appelle NickN maintient un long post sur le forum sur son point de vue sur la construction d’un ordinateur puissant (destiné à jouer à Flight Simulator X de Microsoft, un logiciel très exigeant).
Il résume des points quelque part sur les lecteurs SSD et conclut la liste comme suit:
NE PAS PARTAGER SSD
Malheureusement, il ne précise pas ce point, mais je me demande pourquoi il dit cela. Quels sont les inconvénients du partitionnement d'un SSD? (Partitionner dans ce contexte signifie> = 2 partitions)
Je répète, les disques SSD ne fonctionnent PAS au niveau du système de fichiers!
Il n'y a pas de corrélation 1: 1 entre la façon dont le système de fichiers voit les choses et la façon dont le SSD voit les choses.
N'hésitez pas à partitionner le SSD comme vous le souhaitez (en supposant que chaque partition est correctement alignée et qu'un système d'exploitation moderne gérera tout cela à votre place); cela ne nuira à rien, cela n'affectera PAS les temps d'accès ni quoi que ce soit d'autre, et ne vous inquiétez pas non plus de faire une tonne d'écritures sur le SSD. Ils les ont afin que vous puissiez écrire 50 Go de données par jour, et cela durera 10 ans.
Répondre à Réponse de Robin Hood ,
Le nivellement d'usure n'aura pas autant d'espace libre pour jouer, car les opérations d'écriture seront réparties sur un espace plus petit, de sorte que vous "pourriez", mais n'affectera pas nécessairement cette partie du lecteur plus rapidement que si le lecteur entier était une partition unique, à moins que vous n'effectuiez une usure équivalente sur les partitions supplémentaires (par exemple, un démarrage double).
C'est totalement faux. Il est impossible d'user une partition car vous ne pouvez lire/écrire que sur cette partition. Ce n'est PAS même à distance comment fonctionnent les disques SSD.
Un SSD fonctionne à un niveau d'accès beaucoup plus faible que ce que voit le système de fichiers; un SSD fonctionne avec des blocs et des pages.
Dans ce cas, ce qui se passe réellement est que, même si vous écrivez une tonne de données dans une partition spécifique, le système de fichiers est contraint par la partition, MAIS le SSD ne l’est pas. Plus le SSD écrit écrit, plus le SSD échangera de blocs/pages afin de niveler l'usure. Il s'en fout comment le système de fichiers voit les choses! Cela signifie qu'à un moment donné, les données peuvent résider dans une page spécifique du disque SSD, mais qu'à un autre moment, elles peuvent et seront différentes. Le SSD gardera une trace de la destination des données, et le système de fichiers n'aura aucune idée de l'emplacement réel des données sur le SSD.
Pour rendre cela encore plus facile, écrivez un fichier sur la partition 1. Le système d’exploitation informe le système de fichiers des besoins en stockage, attribue les "secteurs", puis indique au SSD dont il a besoinXQuantité d'espace. Le système de fichiers voit le fichier à l'adresse Adresse du bloc logique (LBA) de 123 (par exemple). Le SSD note que LBA 123 utilise un bloc/page n ° 500 (par exemple). Ainsi, chaque fois que le système d'exploitation a besoin de ce fichier spécifique, le SSD aura un pointeur sur la page exacte qu'il utilise. Maintenant, si nous continuons à écrire sur le disque SSD, que l'usure se met à niveau et que nous disons bloc/page n ° 500, nous pouvons mieux vous optimiser au bloc/page n ° 2300. Désormais, lorsque le système d'exploitation demande ce même fichier et que le système de fichiers demande à nouveau LBA 123, CETTE FOIS, le disque SSD renvoie le bloc/la page n ° 2300 et NOT # 500.
Comme les disques durs, les disques SSD nand-flash ont un accès séquentiel. Ainsi, toutes les données écrites/lues à partir de partitions supplémentaires seront plus éloignées qu'elles "auraient pu l'être si elles avaient été écrites dans une seule partition, car les utilisateurs laissent généralement de l'espace libre". leurs partitions. Cela augmentera les temps d'accès pour les données stockées sur les partitions supplémentaires.
Non, c'est encore faux! Robin Hood réfléchit au système de fichiers au lieu de penser exactement à la manière dont fonctionne un SSD. Là encore, le système de fichiers ne dispose d'aucun moyen de savoir comment le SSD stocke les données. Il n'y a pas de "plus loin" ici; c'est seulement aux yeux du système de fichiers, PAS à la manière dont un SSD stocke les informations. Il est possible que le disque SSD dispose de données réparties dans différentes puces NAND et que l'utilisateur ne remarque aucune augmentation des temps d'accès. Heck, en raison de la nature parallèle de la NAND, elle pourrait même finir par être plus rapide qu'avant, mais nous parlons de nanosecondes ici; clignez des yeux et vous l'avez manqué.
Moins d'espace total augmente le risque d'écriture de fichiers fragmentés et, bien que l'impact sur les performances soit faible, gardez à l'esprit qu'il est généralement considéré comme une mauvaise idée de défragmenter un S.S.D. nand-flash. parce que cela va porter le lecteur. Bien sûr, en fonction du système de fichiers que vous utilisez, le niveau de fragmentation est extrêmement faible, car ils sont conçus pour écrire des fichiers dans leur ensemble, lorsque cela est possible, plutôt que de tout effacer pour créer des vitesses d'écriture plus rapides.
Non désolé; encore une fois c'est faux. La vue des fichiers du système de fichiers et la vue de ces mêmes fichiers par le SSD ne sont même pas proches à distance. Le système de fichiers peut voir le fichier fragmenté dans le pire des cas, MAIS, la vue SSD des mêmes données est presque toujours optimisée.
Ainsi, un programme de défragmentation examinerait ces LBA et dirait que ce fichier doit vraiment être fragmenté! Mais, puisqu'il n'a aucune idée des composants internes du SSD, il est totalement faux. C’est la raison pour laquelle un programme de défragmentation ne fonctionnera pas sur les disques SSD, et oui, un programme de défragmentation provoque également des écritures inutiles, comme cela a été mentionné.
La série d'articles Codage pour disques SSD est un bon aperçu de ce qui se passe si vous souhaitez être plus technique sur le fonctionnement des disques SSD.
Pour un peu plus de "lumière" sur le fonctionnement de FTL (couche de traduction flash), je vous suggère également de lire Rôle critique des couches de micrologiciels et de traduction Flash dans la conception de disques SSD (PDF) à partir de le Flash Memory Summit site.
Ils ont également beaucoup d'autres documents disponibles, tels que:
- Modélisation des couches de traduction Flash pour améliorer la durée de vie du système (PDF)
- Utilisation de la couche de traduction Flash basée sur l'hôte pour une accélération d'application (PDF)
Un autre article explique comment cela fonctionne: Aperçu de la mémoire flash (PDF). Voir la section "Ecriture de données" (pages 26-27).
Si vous préférez la vidéo, consultez Un FTL efficace au niveau de la page pour optimiser la traduction des adresses dans la mémoire flash et les diapositives connexes.
Très longues réponses ici, quand la réponse est assez simple et découle directement de la connaissance générale des disques SSD. Il suffit de lire le terme Wikipedia de Disque SSD pour comprendre la réponse, qui est:
Le conseil "NE PAS PARTAGER SSD" est un non-sens.
Dans le passé (maintenant lointain), les systèmes d'exploitation ne prenaient pas très bien en charge les disques SSD, et en particulier lorsque le partitionnement ne prenait pas soin d'aligner les partitions en fonction de la taille du bloc d'effacement.
Ce manque d’alignement, lorsqu’un secteur de disque logique de système d’exploitation était divisé en blocs SSD physiques, pouvait obliger le SSD à flasher deux secteurs physiques alors que le système d’exploitation n’avait pour objectif que d’en mettre à jour un, ralentissant ainsi l’accès au disque et augmentant Wear Leveling .
À l'heure actuelle, les disques SSD sont de plus en plus volumineux et les systèmes d'exploitation savent tout sur les blocs d'effacement et l'alignement, de sorte que le problème n'existe plus. Peut-être que ce conseil visait autrefois à éviter les erreurs d’alignement des partitions, mais aujourd’hui, ces erreurs sont pratiquement impossibles.
En fait, l'argument en faveur de la partition des disques SSD est aujourd'hui exactement le même que pour les disques classiques:
Pour mieux organiser et séparer les données.
Par exemple, l'installation du système d'exploitation sur une partition distincte et plus petite est pratique pour prendre une image de sauvegarde de celui-ci par précaution lors de la mise à jour volumineuse du système d'exploitation.
Le partitionnement d'un disque SSD ne présente aucun inconvénient et vous pouvez en fait prolonger sa durée de vie en laissant de l'espace non partitionné.
Le nivellement d'usure est appliqué à tous les blocs de périphérique (réf. Papier blanc HP, lien ci-dessous)
Dans le nivellement d'usure statique, tous les blocs de tous les flashs disponibles dans l'appareil participent aux opérations de nivellement d'usure. Cela garantit que tous les blocs reçoivent la même quantité d'usure. Le nivellement d'usure statique est le plus souvent utilisé dans les disques SSD de bureau et portables.
Nous pouvons en déduire que les cloisons n’ont aucune importance pour le nivellement par usure. Cela a du sens car du point de vue du disque dur et du contrôleur, les partitions n’existent pas vraiment. Il y a juste des blocs et des données. Même la table de partition est écrite sur les mêmes blocs (1er bloc du lecteur pour MBR). C'est ensuite le système d'exploitation qui lit la table et décide à quels blocs écrire ou non les données. Le système d'exploitation voit des blocs utiliser LBA pour attribuer un numéro unique à chaque bloc. Cependant, le contrôleur mappe ensuite le bloc logique sur un bloc physique réel en prenant en compte le schéma de mise à niveau.
Le même livre blanc suggère de prolonger la durée de vie du périphérique:
Ensuite, surprovisionnez votre lecteur. Vous pouvez augmenter la durée de vie en ne partitionnant qu’une partie de la capacité totale du périphérique. Par exemple, si vous avez un lecteur de 256 Go, ne le partitionnez que jusqu'à 240 Go. Cela prolongera considérablement la durée de vie du lecteur. Un niveau de surapprovisionnement de 20% (partitionnant seulement 200 Go) prolongerait la durée de vie. En règle générale, chaque fois que vous doublez le surapprovisionnement du lecteur, vous ajoutez 1 fois à l’endurance du lecteur.
Cela suggère également que même un espace non partitionné est utilisé pour le nivellement par usure, prouvant ainsi le point ci-dessus.
Source: Livre blanc technique - SSD Endurance ( http://h20195.www2.hp.com/v2/getpdf.aspx/4AA5-7601ENW.pdf )
Les secteurs de disque ont longtemps été à 512 octets et les disques mécaniques ont pour caractéristique que la seule chose qui affecte le temps nécessaire à la lecture/écriture d'un secteur est le délai de recherche. Ainsi, la principale étape d’optimisation avec les disques durs mécaniques a été d’essayer de lire/écrire des blocs de manière séquentielle afin de minimiser les recherches.
Flash fonctionne très différemment des disques durs mécaniques. Au niveau flash brut, vous n’avez pas de blocs, mais des pages et des "eraseblocks" (à emprunter à la terminologie Linux MTD). Vous pouvez écrire pour faire clignoter une page à la fois et vous pouvez effacer un bloc à la fois.
Une taille de page typique pour flash est 2 Ko, et une taille typique pour eraseblocks est 128 Ko.
Mais les SSD SATA présentent une interface fonctionnant avec des tailles de secteur de 512 octets vers le système d'exploitation.
S'il existe un mappage 1: 1 entre les pages et les secteurs, vous pouvez voir si vous rencontriez des problèmes si votre table de partitions commençait sur une page impaire ou sur une page au milieu d'un bloc d'effacement. Etant donné que les systèmes d'exploitation préfèrent extraire les données des lecteurs de morceaux de 4 Ko, car cela est conforme au matériel de pagination x86, vous pouvez voir comment un tel bloc de 4 Ko pourrait chevaucher un bloc d'effacement, ce qui signifie que sa mise à jour nécessiterait un effacement, puis une réécriture de 2 blocs au lieu de 1. faible performance.
Cependant, le micrologiciel SSD ne conserve pas un mappage 1: 1, il convertit une adresse de bloc physique en une adresse de bloc logique. Cela signifie que vous ne savez jamais où, par exemple, le secteur 5000 ou tout autre secteur donné est réellement écrit. Essayer de toujours écrire dans des blocs effacés préalablement effacés consiste à faire beaucoup de choses en coulisse. Vous ne pouvez pas savoir exactement ce que cela fait sans un désassemblage du micrologiciel, mais à moins que le micrologiciel soit complètement indésirable, le micrologiciel le contourne probablement.
Vous avez peut-être entendu parler des disques durs 4Kn. Ce sont des disques durs techniques qui utilisent en interne une taille de secteur de 4 Ko, mais présentent toujours une interface de secteur de 512 octets avec les systèmes d'exploitation. Cela est nécessaire car les écarts entre les secteurs doivent être réduits sur le plateau pour contenir davantage de données.
Cela signifie qu’en interne, il lit et écrit toujours les secteurs 4K mais le cache du système d’exploitation. Dans ce cas, si vous n'écrivez pas dans des secteurs situés sur une limite de 4 Ko, vous encourez une pénalité de vitesse, car chaque lecture/écriture entraîne la lecture et la réécriture de deux secteurs internes de 4 Ko. Mais cela ne s'applique pas aux disques SSD.
Quoi qu’il en soit, c’est la seule situation à laquelle je puisse penser pourquoi il est suggéré de ne pas partitionner les disques SSD. Mais ça ne s'applique pas.