Compression NTFS sur SSD - hauts et bas
Cette rubrique traite de la compression NTFS sur les disques durs en tant que méthode permettant d'améliorer les performances d'accès au disque et conclut que le résultat est médiocre. Mais j’ai toujours considéré la compression comme un moyen de conserver de l’espace et j’ai appris son efficacité. Et maintenant, j’ai un disque SSD où l’espace est cher et les performances réduites e. g. pour lire/écrire 2 groupes au lieu de 1 est beaucoup plus bas.
D'autre part, les disques SSD étant beaucoup plus rapides que les disques durs, je m'attendrais à ce qu'un débit plus élevé entraîne une utilisation plus importante du processeur. Cela peut-il devenir un problème? Avez-vous d'autres idées à ce sujet?
J'aime l'effet d'économie d'espace, ce n'est pas énorme mais c'est là. Si la performance est une préoccupation, je préférerais l'éteindre:
Microsoft a écrit ceci il y a longtemps dans un blog :
NTFS compresse les fichiers en divisant le flux de données en unités de contrôle (son fonctionnement est similaire à celui des fichiers fragmentés). Lorsque le contenu du flux est créé ou modifié, chaque UC du flux de données est compressée individuellement. Si la compression entraîne une réduction d'un ou plusieurs clusters, l'unité compressée sera écrite sur le disque dans son format compressé. Ensuite, une plage de VCN clairsemée est ajoutée à la fin de la plage de VCN compressée à des fins d'alignement (comme illustré dans l'exemple ci-dessous). Si les données ne sont pas suffisamment compressées pour réduire la taille d'un cluster, l'intégralité de la CU est alors écrite sur le disque sous sa forme non compressée.
Cette conception rend l'accès aléatoire très rapide car une seule CU doit être décompressée pour pouvoir accéder à un seul VCN du fichier. Malheureusement, un accès séquentiel important sera relativement plus lent, car la décompression de nombreuses UC est nécessaire pour effectuer des opérations séquentielles (telles que des sauvegardes).
Et dans un article de la KB , on écrit ceci :
Bien que la compression du système de fichiers NTFS puisse économiser de l'espace disque, la compression des données peut avoir un impact négatif sur les performances. La compression NTFS présente les caractéristiques de performance suivantes. Lorsque vous copiez ou déplacez un fichier NTFS compressé dans un autre dossier, NTFS décompresse le fichier, le copie ou le déplace vers le nouvel emplacement, puis le recompresse. Ce problème se produit même lorsque le fichier est copié ou déplacé entre des dossiers sur le même ordinateur. Les fichiers compressés étant également développés avant la copie sur le réseau, la compression NTFS n'enregistre pas la bande passante du réseau.
La compression NTFS étant gourmande en ressources processeur, le coût en performances est plus visible sur les serveurs, qui sont souvent liés au processeur. Les serveurs fortement chargés avec un trafic d'écriture important sont des candidats médiocres pour la compression de données. Toutefois, vous ne rencontrerez peut-être pas une dégradation significative des performances avec des serveurs en lecture seule, en lecture principale ou peu chargés.
Si vous exécutez un programme qui utilise la journalisation des transactions et écrit en permanence dans une base de données ou un journal, configurez le programme pour stocker ses fichiers sur un volume non compressé. Si un programme modifie les données par le biais de sections mappées dans un fichier compressé, le programme peut produire des pages "sales" plus rapidement que l'écrivain mappé ne peut les écrire. Des programmes tels que Microsoft Message Queuing (également appelé MSMQ) ne fonctionnent pas avec la compression NTFS en raison de ce problème.
Etant donné que les dossiers de base et les profils itinérants des utilisateurs utilisent de nombreuses opérations de lecture et d'écriture, Microsoft vous recommande de placer les dossiers de base et les profils itinérants des utilisateurs sur un volume sans compression NTFS sur le dossier parent ou sur la racine du volume.
Résumé:
ne compressez que les petits fichiers qui ne changent jamais (seules des lectures et des écritures) car les lectures sont rapides, mais les écritures nécessitent une décompression et une nouvelle compression prenant de la puissance CPU et le type de stockage n’ayant pas une grande importance.
Comme Claudio dit beaucoup de choses en détail, je vais reprendre son opinion, qui est aussi la mienne. J'ai constaté les mêmes effets après avoir essayé ce qu’il disait.
Pour SSD, la compression NTFS ne doit pas être utilisée.
Maintenant, je vais énumérer quelques motifs pour une telle affirmation:
Motif n ° 1: Il va tuer plus rapidement la musch SSD, car il fait deux écritures; La compression NTFS écrit toujours les données non compressées avant de démarrer la compression sur RAM, puis réécrit les données compressées uniquement s'il s'agit d'un gain d'au moins 4 Ko.
Motif Nº2: L'utilisation d'un cluster NTFS 4 Ko sur un disque SSD perd 50% de sa vitesse, vérifiez tous les tests de performance et voyez que les blocs de 128 Ko rendent le SSD deux fois plus rapide que l'utilisation de blocs de 4 Ko, et la compression NTFS ne peut être utilisée que sur des partitions NTFS en cluster de 4 Ko.
Motif Nº3: Certains conteneurs (tels que PISMO File Mount) peuvent créer un conteneur qui est perçu comme une compression et/ou un cryptage à la volée. De tels conteneurs font la compression sur RAM et n'envoient pas de données non compressées à disque avant de ré-écrire sur une forme compressée, PISMO obtient également un meilleur taux de compression que NTFS.
Il y a beaucoup plus de motivations, mais ce sont les plus importantes.
Le point ultime est SPEED, toute compression est effectuée sur le processeur. Par conséquent, si vous n’avez pas un processeur très rapide (mono-thread est utilisé pour cela sur NTFS alors que le multi-thread est utilisé sur certains conteneurs), la lecture/écriture sera très lente. lorsqu'il est comprimé; Dans le pire des cas, vous pouvez avoir un processeur très rapide, mais s'il est utilisé pour autre chose (comme le rendu, le transcodage, etc.), il ne reste plus de processeur pour la compression. Vous obtiendrez ainsi de mauvaises performances.
La compression NTFS n’est valable que pour les disques lents traditionnels lorsque vous avez peu de ressources CPU, mais elle nécessite une bonne défragmentation après chaque écriture (au niveau du fichier), car chaque bloc de 64 Ko (compressé ou non) est écrit à un multiple de 64 Ko; le seul moyen de compresser de tels fragments est après la compression (ou l'écriture sur un dossier compressé) de procéder à une défragmentation du fichier.
P.D .: Attention, nous parlons de Windows sur du matériel réel, pas à l'intérieur de machines virtuelles, l'important est de savoir qui écrit sur le support physique, les autres peuvent avoir des couches de cache qui peuvent atténuer les effets et améliorer beaucoup les choses.
Personne ne parle de problème majeur sur non-SSD, il s’agit de la fragmentation.
Chaque bloc de 64 Ko est écrit là où il serait sans compression, mais il peut être compressé, donc au moins <= 60 Ko, il écrit alors moins de 64 Ko, le bloc de bits imbriqués ira là où il se trouverait comme si le précédent n'était pas compresse, donc beaucoup de lacunes apèars.
Testez-le avec un fichier de plusieurs gigaoctets d'une machine virtuelle de n'importe quel système Windows (ils ont tendance à être réduit à 50%, mais avec un énorme> 10000 fragments).
Et pour les SSD, il y a quelque chose qui ne se dit pas, comment diable écrit-il? Je veux dire, si elle l'écrit non compressé puis l'écrase avec une version compressée (pour chaque méga bloc de 64 Ko), la durée de vie du disque SSD est très réduite; mais si elle écrit directement sur une forme compressée, alors SSD live pourrait être plus court ou plus long ... plus long si vous écrivez que 64 Ko seulement à la fois, plus court, beaucoup plus court si vous écrivez que 64 Ko à 4 Ko, car il écrira 64KiB (sous forme comprimée) autant de fois que 64/4 = 16 fois.
La performance est pénalisée par le fait que le temps nécessaire à la compression/décompression doit être supérieur au temps nécessaire pour écrire des blocs de 4 Ko non nécessaires ... avec un processeur très rapide et une compression de disque très lente, le temps d’écriture et de lecture est réduit. très rapide et le processeur est assez lent, il va écrire beaucoup plus lentement.
Quand je parle de processeur rapide ou lent, je veux dire à ce moment-là, le processeur peut être utilisé par "maths" ou par un autre processus, afin de toujours penser au processeur libre, pas aux spécifications du processeur sur papier, de même pour le disque/SSD, cela peut être utilisé par plusieurs processus.
Disons que vous avez 7Zip en train d'écrire un fichier volumineux depuis un autre disque avec LZMA2, il utilisera beaucoup de ressources processeur. Par conséquent, si vous copiez en même temps un fichier compressé NTFS, il ne dispose pas de ressources CPU suffisantes, de sorte qu'il sera plus lent que sans NTFS. compression, mais dès que 7Zip finira par utiliser le processeur, celui-ci sera capable de compresser NTFS plus rapidement, et à ce moment-là, la compression NTFS peut faire les choses plus rapidement.
Personnellement, je n’utilise jamais la compression NTFS, je préfère les conteneurs PFO pour le montage de fichiers PISMO (avec compression, et permet également l’enregistrement, à la fois à la volée et transparent pour les applications), il offre un rapport de compression bien meilleur et moins d’impact de la et écrivez à la volée, pas besoin de décompresser avant de l’utiliser, montez-le et utilisez-le en lecture et en écriture.
Étant donné que PISMO effectue la compression sur RAM avant d'écrire sur le disque, la durée de vie du disque SSD peut durer plus longtemps. Mes tests de compression NTFS me font penser qu'il envoie des données sur le disque deux fois, d'abord non compressé, puis après compression. il est saturé sous forme comprimée.
Pourquoi la vitesse d'écriture compressée NTFS sur mon SSD est-elle proche de la moitié de celle des fichiers non compressés avec des fichiers que de compresser à environ la moitié de sa taille ou de tailles compressées inférieures? Dans mon AMD Threadripper 2950 (32 cœurs et 64 threads) avec 128 Go de RAM (processeur rapide, processeur très rapide) à moins de 1% d'utilisation, il y a donc suffisamment de ressources processeur pour effectuer une compression plus rapide que la vitesse maximale de sauvegarde SSD, peut-être parce La compression NTFS commence après que les blocs de 64 Ko soient envoyés sur le disque non compressés, puis écrasés par la version compressée ... oh, si je le fais sur une machine virtuelle exécutant Linux sur hôte et Windows sur invité, le cache Linux m'informe que de tels clusters sont écrits deux fois. , et la vitesse est beaucoup, beaucoup plus rapide (Linux met en cache les écritures NTFS non compressées envoyées par l’invité Windows et après qu’elles soient écrasées par des données compressées, linux n’envoie pas de données non compressées sur le disque, le cache d’écriture Linux !!!).
Ma recommandation est de ne pas utiliser la compression NTFS, sauf dans les machines virtuelles. Les hôtes exécutent Windows si Host est Linux, et jamais si vous utilisez le processeur de manière plus intensive si votre processeur n’est pas assez rapide.
Le SSD moderne possède un énorme cache en ram interne, de sorte que le système de cache interne du SSD peut atténuer les effets d'écriture et de survol provoqués par la compression NTFS.
Mes tests étaient effectués sur de "jolis" SSD sans mémoire interne RAM pour la mémoire cache à l'intérieur du disque SSD. Lorsque je les répète sur ceux dotés d'une mémoire cache RAM, la vitesse d'écriture est plus rapide, mais pas comme on pourrait le penser.
Faites vos propres tests et utilisez d’énormes tailles de fichiers (plus grand que le total de tam installé pour éviter les résultats cachés du cache).
En passant, quelque chose que certaines personnes ne connaissent pas à propos de la compression NTFS ... aucun fichier de 4 Ko ou moins ne sera jamais compressé en NTFS car il n’ya aucun moyen de réduire sa taille d’au moins 4 Ko.
La compression NTFS prend un bloc de 64 Ko, compressez-les et si elle peut réduire un cluster (4 Ko), alors il est écrit compressé, 64 Ko sont 16 blocs de 4 Ko (consécutifs).
Si un fichier de 8 Ko à la fin de la compression, le résultat final est supérieur à 4 Ko, il ne sauvegarde aucun cluster. Il est donc écrit non compressé, etc., etc., la pression doit gagner au moins 4 Ko.
Ah, et pour la compression NTFS, le NTFS doit avoir une taille de cluster de 4 Ko.
Essayez de faire un test: utilisez un cluster de 128 Ko sur un NTFS sur SSD. Vous constaterez une amélioration considérable des performances en écriture et en vitesse de lecture.
Les systèmes de fichiers sur SSD avec cluster 4Ko perdent beaucoup de leur vitesse, dans la plupart des cas plus de 50% de pertes ... voyez tous les tests de performances testés avec des tailles de blocs différentes, de 512 octets à 2 Mo, la plupart des écritures SSD en double la vitesse sur une taille de cluster de 64 Ko (ou 128 Ko) à celle de 4 Ko.
Vous voulez une vraie imptivement sur votre SSD? N'utilisez pas le cluster 4KiB sur le système de fichiers, utilisez 128KiB.
Utilisez le cluster 4 Ko seulement si plus de 99% de vos fichiers sont inférieurs à 128 Ko.
Etc, etc, etc ... testez, testez et testez votre propre cas.
Remarque: Créez la partition NTFS système avec diskpart en mode console lors de l'installation de Windows avec un cluster de 128 Ko, ou à partir d'un autre Windows, mais ne laissez pas le formatage de Windows dans la partie graphique de l'installateur (il sera toujours formaté en cluster NTFS de 4 Ko).
Tous mes Windows sont maintenant installés sur une partition NTFS de cluster de 128 Ko sur plus de 400 Go de SSD (SLC).
J'espère que les choses deviendront claires, M $ ne dit pas comment il écrit NTFS compressé, mes tests me disent qu'il écrit deux fois (64 Ko non compressés, puis <= 60 Ko compilés), et pas seulement une fois (méfiez-vous de cela si sur SSD).
Attention: Windows essaie de compresser NTFS certains répertoires internes, peu importe si vous dites non compressé NTFS, le seul moyen d'éviter réellement cette situation si la taille de cluster NFTS est différente de 4 Ko, car la compression NTFS ne fonctionne que sur des partitions NTFS de taille de cluster 4 Ko