L'icône rouge permet de télécharger chaque page du wiki visitée au format PDF et la grise au format ODT →

Différences

Ci-dessous, les différences entre deux révisions de la page.

--- doc:materiel:disques-durs [22/09/2018 18:45]
smolski swap partitionnement
+++ doc:materiel:disques-durs [10/08/2021 17:27] (Version actuelle)
smolski [Préalable]
@@ Ligne 101: / Ligne 101: @@
 **raleur :** \\
 C'est faux. swappiness définit une tendance, pas le seuil d'occupation de la mémoire au-delà duquel le swap va se déclencher. Ce n'est pas la première fois que je vois cette confusion.
+==== Partitionnement ====
 **Aigle-Royal a écrit :**
@@ Ligne 115: / Ligne 117: @@
 Cette valeur de 50% est totalement arbitraire et exagérée, mais le conseil a un fond de vérité.
-Un SSD a besoin d'espace libre pour fonctionner efficacement. C'est lié au principe de l'écriture en mémoire flash : contrairement à un support magnétique comme un disque dur où on peut réécrire physiquement les nouvelles données par dessus des anciennes au même emplacement, on ne peut écrire en mémoire flash que dans un emplacement vierge, c'est-à-dire préalablement effacé. Or l'effacement d'un bloc de mémoire flash a deux gros inconvénients : c'est lent, et la taille d'un bloc d'effacement est plus grosse que la taille d'un bloc d'écriture. Si certaines données du bloc à effacer doivent être préservées, elles doivent d'abord être copiées (écrites) dans d'autres blocs vierges. Il est donc hors de question d'effacer un bloc juste avant d'y écrire, ce serait affreusement lent et coûteux. Pour un fonctionnement optimal en écriture, le SSD doit toujours disposer de suffisamment de blocs vierges prêts à l'écriture.
+Un SSD a besoin d'espace libre pour fonctionner efficacement. C'est lié au principe de l'écriture en mémoire flash : contrairement à un support magnétique comme un disque dur où on peut réécrire physiquement les nouvelles données par dessus des anciennes au même emplacement, on ne peut écrire en mémoire flash que dans un emplacement vierge, c'est-à-dire préalablement effacé. Or l'effacement d'un bloc de mémoire flash a deux gros inconvénients : \\
+c'est lent, et la taille d'un bloc d'effacement est plus grosse que la taille d'un bloc d'écriture.
+Si certaines données du bloc à effacer doivent être préservées, elles doivent d'abord être copiées (écrites) dans d'autres blocs vierges. Il est donc hors de question d'effacer un bloc juste avant d'y écrire, ce serait affreusement lent et coûteux. Pour un fonctionnement optimal en écriture, le SSD doit toujours disposer de suffisamment de blocs vierges prêts à l'écriture.
 Les SSD ont déjà une certaine quantité de mémoire flash "cachée" (car pas comptée dans la capacité utilisable) qui sert précisément à cela. On appelle cela "overprovisioning". Par exemple, compte tenu du fait que la capacité d'une puce de mémoire flash est une puissance entière de 2, il est probable qu'un SSD de 120 Go a une capacité brute de 128 Gio, soit 137 Go, donc 137 - 120 = 17 Go, soit 14% d'overprovisioning.
 Ne pas utiliser une partie de la capacité d'un SSD contribue aussi à augmenter le stock de blocs vierges. Il y a deux façons :
-- ne pas occuper tout l'espace avec le système de fichiers ;
+  - ne pas occuper tout l'espace avec le système de fichiers ;
-- occuper tout l'espace avec le système de fichiers mais ne pas remplir le système de fichiers au delà d'un certain seuil (à condition d'utiliser la fonction TRIM avec l'option "discard" pour marquer les blocs des fichiers effacés).
+  - occuper tout l'espace avec le système de fichiers mais ne pas remplir le système de fichiers au delà d'un certain seuil (à condition d'utiliser la fonction TRIM avec l'option "discard" pour marquer les blocs des fichiers effacés).
 La seconde option a un avantage : un système de fichiers fonctionne également mieux lorsqu'il a beaucoup d'espace libre, cela lui permet d'optimiser l'allocation des blocs. Ainsi il va pouvoir allouer un grand nombre de blocs consécutifs à chaque fichier au lieu de chercher à "remplir les trous".
@@ Ligne 137: / Ligne 142: @@
 //Que ses pas suivent un chemin pavé de pétale de roses...// LOL
+==== NVMe ====
+**raleur :** L'accès à la RAM reste plus rapide que l'accès à un SSD même de type NVMe, pour une raison évidente : les données doivent d'abord être lues depuis le SSD et copiées en RAM avant de pouvoir être utilisées.\\
+Jusqu’alors, afin de s’insérer de façon transparente dans nos ordinateurs, les SSD ont donc choisi en quelque sorte de se faire passer pour des disques durs, et il a été impossible d’en tirer la quintessence via les bus standards comme SATA ou SAS. Les gains de performances face à un disque dur sont certes impressionnants, mais ils le seraient encore plus si les SSD étaient reliés directement à un bus rapide et piloté via un jeu de commande optimisé, à même de tirer parti de leurs spécificités.
+C’est tout le but de NVMe. Les principaux bénéfices du standard sont une forte réduction de la latence, un accroissement du niveau d’IOPS (via notamment une augmentation des files d’attente et un plus grand parallélisme) et une réduction de la consommation par rapport aux SSD SAS ou SATA (une pile I/O simplifiée requérant moins d’opérations de la part du contrôleur du disque permet d’en réduire la consommation électrique).
+NVMe supporte également le multipathing (plusieurs contrôleurs PCI-e d’une même machine peuvent fournir des chemins vers un périphérique unique pour plus de résilience) et une gestion avancée des espaces de noms (pour permettre par exemple le partage d’un périphérique SSD NVMe par plusieurs serveurs via un mécanismes de virtualisation tels que Multi-Root-IOV).
+  * Source : https://www.lemagit.fr/definition/NVMe
+  * Installation debian : [[doc:install:uefi#nvme|Installation debian buster sur NVME]]
 ===== Applications =====

doc/materiel/disques-durs.1537634723.txt.gz · Dernière modification: 22/09/2018 18:45 par smolski

Debian-facile

Différences

Pied de page des forums