Compression NTFS sur SSD - hauts et bas

Cette rubrique traite de la compression NTFS sur les disques durs en tant que méthode d'amélioration des performances d'accès au disque et conclut qu'elle est médiocre le plus souvent. 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 SSD où l'espace est cher et la pénalité de performance, par exemple pour lire / écrire 2 clusters au lieu de 1, est beaucoup plus faible.

D'un autre côté, étant donné que les SSD sont beaucoup plus rapides que les disques durs, je m'attends à ce qu'un débit plus élevé entraîne une utilisation plus élevée du processeur. Cela peut-il devenir un problème? Avez-vous d'autres réflexions à ce sujet?

J'aime l'effet d'économie d'espace, ce n'est pas énorme mais il est là. Si les performances sont un problème, je préfère toutefois les désactiver:

Microsoft l'a écrit il y a quelque temps dans un blog :

NTFS compresse les fichiers en divisant le flux de données en CU (c'est similaire à la façon dont les fichiers épars fonctionnent). 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 VCN clairsemée est clouée à la fin de la plage 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, la CU entière est écrite sur le disque sous sa forme non compressée.

Cette conception rend l'accès aléatoire très rapide puisqu'un seul CU doit être décompressé pour accéder à n'importe quel VCN unique dans le 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 écrit ceci :

Bien que la compression du système de fichiers NTFS puisse économiser de l'espace disque, la compression des données peut nuire aux performances. La compression NTFS présente les caractéristiques de performances suivantes. Lorsque vous copiez ou déplacez un fichier NTFS compressé vers un autre dossier, NTFS décompresse le fichier, copie ou déplace le fichier vers le nouvel emplacement, puis recompresse le fichier. 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 sont également développés avant d'être copiés sur le réseau, de sorte que la compression NTFS n'économise pas la bande passante réseau.

Étant donné que la compression NTFS est gourmande en ressources processeur, le coût des performances est plus sensible sur les serveurs, qui sont souvent liés au processeur. Les serveurs lourdement chargés avec beaucoup de trafic d'écriture sont de mauvais candidats pour la compression de données. Cependant, vous ne pouvez pas rencontrer de dégradation significative des performances avec des serveurs en lecture seule, en lecture seule ou légèrement chargés.

Si vous exécutez un programme qui utilise la journalisation des transactions et qui écrit constamment dans une base de données ou un journal, configurez le programme pour stocker ses fichiers sur un volume qui n'est pas compressé. Si un programme modifie des données via des sections mappées dans un fichier compressé, le programme peut produire des pages "sales" plus rapidement que le rédacteur 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.

Étant donné que les dossiers de départ utilisateur et les profils itinérants utilisent de nombreuses opérations de lecture et d'écriture, Microsoft vous recommande de placer les dossiers de départ utilisateur et les profils itinérants sur un volume qui n'a pas de compression NTFS dans le dossier parent ou à la racine du volume.

Sommaire:

compresser uniquement les petits fichiers qui ne changent jamais (uniquement les lectures et pas d'écriture) car les lectures sont rapides, mais les écritures nécessitent une décompression et une nouvelle compression qui nécessite de la puissance CPU et le type de stockage n'est pas si important.

Comme Claudio dit beaucoup de choses en détail, je vais reprendre son opinion qui est aussi la mienne, j'ai vu les mêmes effets après avoir essayé ce qu'il dit.

Pour SSD, la compression NTFS ne doit pas être utilisée.

Je vais maintenant énumérer quelques motifs pour une telle affirmation:

Motif Nº1: Il tuera le musch SSD plus rapidement, car il fait deux écritures; La compression NTFS écrit toujours les données non compressées avant de commencer la compression sur la RAM, puis de réécrire 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 4KiB sur un SSD perd 50% de la vitesse du SSD, vérifiez n'importe quelle référence et verrez que les blocs de 128 Ko rendent le SSD deux fois plus rapide que l'utilisation des blocs 4KiB, et la compression NTFS ne peut être utilisée que sur les partitions NTFS du cluster 4KiB.

Motif Nº3: Il existe des conteneurs (comme PISMO File Mount) qui peuvent créer un conteneur qui est considéré comme une compression et / ou un cryptage à la volée, ces continers font la compression sur RAM et n'envoient pas de données non compressées sur le disque avant la réécriture sous forme compressée, PISMO obtient également un meilleur taux de compression que NTFS.

Il y a beaucoup plus de motifs, mais ce sont les plus importants.

Le point de départ est SPEED, toute compression est effectuée sur le CPU, donc si vous n'avez pas de CPU très rapide (le mono-thread est utilisé pour cela sur NTFS tandis que le multi-thread est utilisé sur certains conteneurs), la lecture / écriture sera très lente une fois compressé; le pire, vous pouvez avoir un processeur très rapide, mais s'il est utilisé pour d'autres choses (comme le rendu, le transcodage, etc.), il n'y a plus de processeur pour la compression, donc vous obtiendrez à nouveau de mauvaises performances.

La compression NTFS n'est bonne que pour les disques lents traditionnels lorsque vous avez un processeur sans grande utilisation, 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; la seule façon d'emballer de tels fragments est après la compression (ou d'écrire sur un dossier compressé) de défragmenter ce fichier.

PD: 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, d'autres peuvent avoir des couches de cache qui peuvent atténuer les effets et également améliorer beaucoup les choses.

Personne ne parle de problème de maire sur des disques non SSD, c'est de la fragmentation.

Chaque bloc de 64 Ko est écrit là où il serait sans compression, mais il peut être compressé, donc au moins est <= 60 Ko, puis il écrit moins de 64 Ko, le bloc d'imbrication de bits ira où il le ferait comme si le précédent n'était pas compresser, donc beaucoup de lacunes apèars.

Testez-le avec un fichier de plusieurs gigaoctets d'une machine virtusl de n'importe quel système Windows (ils ont tendance à être réduits à 50%, mais avec un énorme> 10000 fragments).

Et pour les SSD, il y a quelque chose qui n'est pas dit, comment diable écrit-il? Je veux dire, s'il l'écrit non compressé puis l'écrase avec une version compressée (pour chaque méga-blocs de 64 Ko), la durée de vie du SSD est considérablement réduite; mais s'il l'écrit directement sous forme compressée, alors le SSD en direct pourrait être plus lent ou plus court .... plus long si vous n'écrivez que 64 Ko seulement en une fois, plus court, plus court si vous écrivez ces 64 Ko en 4KiB, car il écrira un tel 64 Ko (sous forme compressée) autant de fois que 64/4 = 16 fois.

La pénalité de performance est due au fait que le temps CPU nécessaire pour compresser / décompresser est plus long que le temps gagné sur pas besoin d'écrire des blocs 4KiB ... donc avec un CPU très rapide et une compression de disque très lente réduit le temps d'écriture et de lecture, mais si le SSD est très rapide et le processeur est assez lent, il écrira beaucoup plus lentement.

Quand je parle de CPU rapide ou lent, je veux dire à ce moment-là, le CPU peut être utilisé par des `` maths '' ou d'autres processus, alors pensez toujours au processeur gratuit, pas aux spécifications du CPU sur papier, il en va de même pour le disque / SSD, il peut être utilisé par plusieurs processus.

Supposons que 7Zip écrive un fichier énorme à partir d'un autre disque avec LZMA2, il utilisera beaucoup de CPU, donc si en même temps vous copiez un fichier compressé NTFS, il n'a pas de CPU libre, donc ça ira plus lentement que sans NTFS la compression, mais dès que 7Zip finira d'utiliser le CPU, ce CPU pourra compresser NTFS plus rapidement, et à ce moment la compression NTFS peut faire les choses plus rapidement.

Personnellement, je n'utilise jamais la compression NTFS, je préfère les conteneurs PFO à montage de fichiers PISMO (avec compression, et il permet également une inscription, à la fois et transparente aux applications), il donne un bien meilleur taux de compression et moins d'impact sur le processeur, alors qu'il s'agit d'une lecture et écrivez à la volée, pas besoin de décompresser avant utilisation, montez-le et utilisez-le en mode lecture et écriture.

Étant donné que PISMO effectue la compression sur la RAM avant d'écrire sur le disque, il peut faire durer le SSD 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ées, et ensuite s'il peut compresser, il est écrasé sous forme compressée .

Pourquoi la vitesse d'écriture compressée NTFS sur mon SSD est près de la moitié de celle non compressée avec des fichiers que compresser à près de la moitié de sa taille ou des tailles compressées inférieures? Dans mon AMD Threadripper 2950 (32 cœurs et 64 threads) avec 128 Go de RAM (CPU rapide, CPU très rapide) à moins de 1% d'utilisation, il y a donc beaucoup de CPU pour faire la compression plus rapidement que la vitesse sécuentielle maximale du SSD, peut-être parce que La compression NTFS commence après que les blocs de 64 Ko sont envoyés sur le disque non compressés puis remplacés par la version compressée ... oh si je le fais sur une machine virtuelle exécutant Linux sur l'hôte et Windows sur l'invité, le cache Linux m'informe que ces 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 depuis qu'elles sont écrasées par des données compressées, Linux n'envoie pas de données non compressées sur le disque,

Ma recommandation, n'utilisez pas la compression NTFS, sauf à l'intérieur des machines virtuelles, les invités exécutent des fenêtres si l'hôte est Linux, et jamais si vous utilisez beaucoup le CPU si votre CPU n'est pas assez rapide.

Le SSD moderne possède un énorme cache de mémoire RAM interne, de sorte que l'écriture + la surcharge provoquée par la compression NTFS peuvent être atténuées par le système de cache interne du SSD.

Mes tests ont été effectués sur de "jolis" SSD sans RAM interne pour le cache à l'intérieur du SSD, quand je les répète sur ceux avec un cache RAM, la vitesse d'écriture est rapide, mais pas comme on pourrait le penser.

Faites vos propres tests et utilisez des fichiers volumineux (plus gros que le tam tam installé pour éviter les résultats cachés du cache).

Soit dit en passant, quelque chose que certaines personnes ne connaissent pas sur la vompression NTFS ... tout fichier de 4 Ko ou moins n'obtiendra jamais de compression NTFS car il n'y a aucun moyen de réduire sa taille d'au moins 4 Ko.

La compression NTFS prend 64 Ko de compression, les comprime et si elle peut réduire un cluster (4 Ko), elle est écrite compressée, 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 peut enregistrer aucun cluster, il est donc écrit non compressé, ... et ainsi de suite ... 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 verrez une amélioration considérable des performances sur les vitesses d'écriture et de lecture.

Les systèmes de fichiers sur SSD avec cluster 4KiB perdent beaucoup de leur vitesse, dans la plupart des cas, plus de 50% perdus ... voir tous les benchmarks qui testent avec différentes tailles de bloc, de 512Bytes à 2MiB, la plupart des SSD écrivent à double vitesse lorsque sur une taille de cluster de 64 Ko (ou 128 Ko) que sur 4 Ko.

Vous voulez un vrai imptivement sur votre SSD? N'utilisez pas de cluster de 4 Ko sur le système de fichiers, utilisez 128 Ko.

Utilisez uniquement un cluster de 4 Ko si plus de 99% de vos fichiers sont inférieurs à 128 Ko.

Etc, etc, etc ... testez, testez et testez votre propre boîtier.

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 du programme d'installation (il le formatera toujours en tant que cluster NTFS de 4 Ko).

Tous mes Windows sont maintenant installés sur une partition NTFS de cluster de 128 Ko sur un SSD> 400 Go (SLC).

J'espère que les choses seront claires, M $ ne dit pas comment iy écrit NTFS compressé, mes tests me disent qu'il écrit deux fois (64 Ko non compressés, puis <= 60 Ko compilés), pas une seule fois (attention à cela si sur SSD).

Attention: Windows essaie de compresser NTFS certains répertoires internes, peu importe si vous dites pas de compression NTFS, le seul moyen d'éviter vraiment cela si la taille du cluster NFTS est différente de 4KiB, car la compression NTFS ne fonctionne que sur les partitions NTFS de taille de cluster 4KiB

Je vois les commentaires des autres, et je pense que les gens oublient souvent le scénario le plus utile où la compression de fichiers / dossiers NTFS a un grand avantage sur SSD: les outils de développement modernes. Mon Matlab sous licence universitaire a dans son dossier d'installation (pour l'utilisateur ordinaire en lecture seule) les quantités de données suivantes:

28,5 Go de données 30,6 Go de taille sur le disque Contient 729.246 fichiers et 15.000 dossiers (!!!)

C'est sur mon ordinateur portable avec 500 Go de SSD, où la partition Windows est de 200 Go.

Je sais que Matlab est un peu extrême à cet égard, mais de nombreux devtools ont des propriétés similaires: une tonne de petits fichiers texte hautement compressibles (en-têtes, code, fichiers XML). Je suis en train de compresser Matlab avant d'installer le devtool Intel Quartus FPGA , et Octave est déjà compressé comme suit:

1,55 Go Taille des données sur le disque: 839 Go Contient 34,362 fichiers 1,955 dossiers

Ce truc est écrit une fois, et lit des millions de fois lors des builds de projet. Il est parfaitement logique de dépenser une partie de la puissance du processeur pour le décompresser et économiser peut-être la moitié de votre précieux espace SSD.

Vous devez comparer deux fois pour savoir. Comprimé. Non compressé. Oubliez l'usure des SSD. Vous avez besoin d'un SSD et d'un CPU rapides pour éviter tout goulot d'étranglement.

Un SSD de 512 Go coûte 50 dollars de nos jours. Jusqu'à présent, l'accès au disque le plus rapide consiste à utiliser Linux dans la mesure du possible et le mécanisme de file d'attente de disque LIFO. Plutôt que CFQ.

Windows 10 crée une activité de disque infinie avec 12 Go de RAM installés sur mon ordinateur portable. Linux se charge et presque zéro accès au disque se produit après. Sauf si vous l'initiez. Windows a juste un moyen de se tenir occupé sans tâches visibles.