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 [22/09/2018 18:50]
smolski [Préalable]
@@ Ligne 115: / Ligne 115: @@
 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".

doc/materiel/disques-durs.txt · Dernière modification: 10/08/2021 17:27 par smolski

Debian-facile

Différences

Pied de page des forums