Les fichiers qui utilisent la compression NTFS sont-ils décompressés sur le disque ou en mémoire?

Comment fonctionne la décompression NTFS sous Windows? Selon Microsoft, la décompression NTFS se fait en développant le fichier, puis en l'utilisant. Cela semble juste, mais ma question est de savoir comment ce processus se déroule techniquement.

Windows charge-t-il le fichier compressé en mémoire, le développe-t-il en mémoire et lit-il à partir de la mémoire? Ou charge-t-il le fichier compressé en mémoire, le développe-t-il sur le disque ou en mémoire, écrit-il sur le disque, puis lit-il?

J'essaie de comprendre si je peux peut-être améliorer les performances de mon ordinateur en utilisant la compression NTFS. De cette façon, le lecteur de disque lent ou le SSD qui ne peut pas gérer autant d'opérations d'écriture aura toujours moins de données à écrire et à lire, et mon puissant processeur qui tourne au ralenti la plupart du temps peut décompresser les fichiers, améliorant ma vitesse de stockage et ma santé .

windows ntfs

— CausingUnderflowsEverywhere
source

J'ai modifié votre question pour vous concentrer davantage sur la décompression des fichiers en mémoire ou sur disque. De cette façon, il sera beaucoup moins susceptible d'être fermé en tant que double de cette autre question , qui touche davantage aux autres aspects.

— Ben N

Windows décompresse les fichiers en mémoire. Le faire sur le disque annulerait complètement toute amélioration de la vitesse et entraînerait beaucoup d'écriture inutile sur le disque. Consultez la fin de cet article de blog Microsoft sur les fichiers clairsemés NTFS et la compression :

NTFS détermine l'unité de compression à laquelle vous accédez.

La plage allouée entière de l'unité de compression est lue.

Si l'unité n'est pas compressée, nous passons à l'étape 5. Sinon, NTFS tentera de réserver (mais pas d'allouer) l'espace requis pour réécrire la CU décompressée sur le disque. S'il n'y a pas suffisamment d'espace libre sur le disque, l'application peut obtenir un ERROR_DISK_FULL pendant la lecture.

Le CU serait décompressé en mémoire .

La plage d'octets décompressée serait mappée dans le cache et renvoyée à l'application demandeuse.

...

Bien sûr, si vous manquez de mémoire, la mémoire utilisée par le processus de décompression peut entraîner la pagination de l'autre mémoire et l'écriture sur le disque dans le fichier d'échange. Heureusement, seuls les morceaux contenant des sections que vos programmes lisent réellement seront décompressés; NTFS n'a pas à décompresser le tout si vous n'avez besoin que de quelques octets.

Si votre SSD est rapide, vous n'obtiendrez probablement pas d'amélioration de la vitesse de la compression NTFS. Il est concevable que le temps que votre processeur passe à décompresser les données plus le temps que votre disque passe à lire les données compressées puisse être supérieur au temps que prend votre SSD pour lire les données non compressées. Cela dépend également de la taille des fichiers avec lesquels vous travaillez. La taille minimale d'un fichier compressible varie de 8 Ko à 64 Ko, selon la taille de votre cluster. Tous les fichiers inférieurs à cette taille ne seront pas compressés du tout, mais une petite quantité de comptabilité serait ajoutée.

Si vous faites beaucoup d'écriture dans des fichiers compressés, vous pourriez voir beaucoup de variance de vitesse en raison de l'algorithme de compression utilisé (LZ).

Pour en savoir plus: Comment la compression NTFS affecte-t-elle les performances?

— Ben N
source

> si vous manquez de mémoire, les données décompressées peuvent être paginées et écrites sur le disque dans le fichier d' échange [citation nécessaire] - un algorithme intelligent jetterait simplement les données décompressées et effectuerait à nouveau la décompression lors du prochain accès, avec l'hypothèse de (dé) compression étant des ordres de grandeur plus rapide que la radiomessagerie. En fait, c'est déjà ce qui se passe avec le cache de pages - et je m'attends à ce que Windows place simplement ces données décompressées dans ce même cache. (Sous Windows, tous les fichiers r / w passent par le cache de page, même lorsqu'ils sont écrits en écriture.)

— Bob

En effet, c'est probablement ce qu'il fait. J'ai ajusté cette partie de la réponse, merci.

— Ben N

"La plage d'octets décompressée serait mappée dans le cache " Savez-vous quelle est la définition du cache ici? Juste curieux. ----- "Sinon, NTFS tenterait de réserver l'espace requis pour réécrire la CU décompressée sur le disque." Connaissons-nous la raison exacte de cela? Microsoft suppose-t-il ici que la modification du fichier n'ajoutera pas de taille qui fera que la taille compressée totale dépassera la taille non compressée d'origine? On dirait une supposition idiote.

— CausingUnderflowsEverywhere

Donc, en résumé, nous examinons: lire à partir du disque, -> lire MFT pour vérifier suffisamment d'espace pour écrire décompressé, -> décompresser en mémoire, -> le jeter dans le cache de l'application demandeuse? parlons-nous des octets privés de l'application? juste curieux. ---------- C'est ce que nous regardons ici?

— CausingUnderflowsEverywhere

@CausingUnderflowsEverywhere Ce cache est le cache d'E / S , ce qui fait qu'il n'est pas nécessaire que toutes les lectures multiples soient traitées par le disque. NTFS espère que les nouvelles données s'intégreront dans les CU existantes, mais il s'assure qu'il y a de l'espace si ce n'est pas le cas. Je crois comprendre que le cache d'E / S n'est pas spécifique à une application, bien que les données se retrouvent dans la mémoire privée du programme lorsque cela est demandé.

— Ben N