Comment la compression du système de fichiers affecte-t-elle les performances d'écriture d'un NAS domestique ?

La compression du système de fichiers peut accélérer l’écriture d’un NAS domestique lorsqu’elle supprime plus de travail de stockage qu’elle n’ajoute de travail CPU, mais elle peut aussi augmenter la latence.

Le résultat dépend de ce que le NAS stocke, de l’algorithme et du niveau de compression utilisés, et de savoir si le goulot d’étranglement actif est le processeur, le pool de disques ou le chemin d’écriture synchrone. Cet article se concentre sur la compression transparente du système de fichiers — pas les archives ZIP ni la compression SMB — car chacun agit à une étape différente du chemin des données.

Le compromis principal : moins d’octets écrits, plus de travail CPU

La compression transparente se situe dans le chemin d’écriture du système de fichiers. Les applications soumettent des données logiques, le système de fichiers divise ces données en enregistrements ou étendues, et le moteur de compression tente d’encoder chaque unité en moins d’octets avant allocation. Lorsqu’il réussit, moins de blocs atteignent le pool de stockage. Une explication détaillée de la compression transparente du système de fichiers montre pourquoi la taille des enregistrements, le taux de compression et la taille des blocs physiques influencent tous la quantité d’E/S réellement économisée.

Cela crée un échange plutôt qu’un gain de vitesse universel. Le processeur passe du temps à trouver des motifs répétés, mais les disques, SSD, couche de parité et bus de stockage gèrent une charge physique plus faible. Si le temps de dispositif économisé est supérieur au temps de compression, le débit d’écriture visible par l’application augmente. Si le CPU est déjà occupé ou si les données rétrécissent à peine, cette étape supplémentaire peut augmenter la latence d’écriture sans réduire suffisamment les E/S pour compenser.

La vitesse rapportée peut également être mal comprise. Un outil de copie mesure les octets logiques acceptés du client, tandis que les statistiques du disque montrent les octets physiques écrits après compression. Un NAS peut donc indiquer 500 Mo/s de progression logique alors que ses disques reçoivent bien moins de 500 Mo/s. La compression du système de fichiers ne réduit pas automatiquement le trafic SMB entrant ; la compression réseau devrait intervenir plus tôt dans le chemin.

La compressibilité détermine la quantité de travail de stockage qui disparaît

La compression ne supprime du travail que lorsque l’entrée contient des motifs réutilisables. Le texte, les journaux, le code source, les champs de base de données répétés et les zones remplies de zéros ont souvent assez de redondance pour rétrécir considérablement. Les fichiers JPEG, vidéo HEVC, archives ZIP et fichiers chiffrés ont déjà supprimé ou obscurci ces motifs. La relation entre la redondance des données et la compression explique pourquoi deux dossiers NAS de taille égale peuvent produire des résultats d’écriture opposés.

Un NAS domestique ne contient rarement une charge uniforme, donc la question utile n’est pas de savoir si la compression est rapide isolément. C’est de savoir si l’ensemble de données actif devient assez petit pour réduire la partie la plus lente de son propre chemin d’écriture.

L’ordre compte aussi. Les données compressées avant le chiffrement peuvent encore économiser de l’espace, mais le texte chiffré semble normalement à haute entropie pour une couche de système de fichiers ultérieure. De même, une image VM creuse ou partiellement vide peut bien se compresser même si le système d’exploitation à l’intérieur stocke un contenu mixte. Les extensions de fichiers sont des indices utiles, mais pas des mesures fiables des blocs vus par le système de fichiers.

L’algorithme et le niveau de compression déterminent le taux d’échange CPU–E/S

Les algorithmes rapides privilégient un temps de traitement faible et une réduction de taille modérée, tandis que les algorithmes plus lourds passent plus de temps CPU à chercher un meilleur ratio. C’est la même frontière vitesse contre taille visible dans les comparaisons indépendantes des méthodes de compression. Pour un NAS toujours actif, le meilleur ratio n’est pas automatiquement la meilleure performance d’écriture car chaque processus d’écriture en avant-plan et en arrière-plan partage le même processeur.

Le niveau de compression rend cette limite plus granulaire. Les mesures publiées des niveaux Zstandard montrent que la vitesse de compression diminue à mesure que le ratio demandé augmente, tandis que la décompression reste comparativement rapide. Cela rend un niveau élevé attractif pour les écritures d'archivage sur matériel inactif mais potentiellement perturbant pour les bases de données en direct, les journaux de conteneurs ou plusieurs clients écrivant simultanément.

Aucun algorithme ne fournit un résultat universel. La génération du processeur, les cœurs disponibles, la bande passante mémoire, l'implémentation, la taille des chunks et le jeu de données comptent tous. Un algorithme rapide sur un CPU peu puissant peut toujours être le goulot d'étranglement derrière un pool NVMe rapide, tandis qu'un algorithme plus puissant peut rester pratiquement gratuit lorsque des disques lents dominent le même NAS.

Le support de stockage et le mode d'écriture déplacent le goulot d'étranglement.

Les disques rotatifs offrent généralement plus d'opportunités pour que la compression aide, car chaque bloc supprimé évite un travail relativement coûteux sur le périphérique. Un pool NVMe peut absorber beaucoup plus de données avant que le stockage ne devienne la limite, donc le temps CPU de compression est plus facile à mettre en évidence. Le principe plus large est que le travail CPU peut remplacer les E/S de stockage, mais la ressource la mieux utilisée dépend de l'équilibre réel du matériel.

La forme d'écriture change aussi la réponse. Les grands flux asynchrones laissent au système de fichiers la possibilité de regrouper et de paralléliser le travail. Les petites mises à jour synchrones attendent toujours les accusés de réception de durabilité, donc une taille de charge réduite ne supprime pas la latence fixe d'un vidage ou d'un engagement de journal. Les implémentations de systèmes de fichiers compressent également par unités spécifiques : le comportement actuel de la compression Btrfs, par exemple, utilise des chunks limités, un traitement parallèle et des règles spécifiques à l'implémentation qui peuvent modifier l'utilisation des métadonnées et la latence d'écriture.

La concurrence ajoute une autre limite. Plusieurs sauvegardes, bases de données d'applications, importations de médias et écritures de conteneurs peuvent collectivement saturer le CPU même lorsque chaque flux en bénéficie individuellement. La compression doit donc être interprétée en tenant compte des goulots d'étranglement du réseau, de la mémoire, du disque et des tâches en arrière-plan, surtout lorsque le débit chute uniquement pendant les tâches planifiées ou l'activité multi-utilisateurs.

Les benchmarks de compression doivent comparer le travail logique et physique

Un benchmark rempli de zéros ou d'octets répétés peut faire paraître un système de fichiers compressé plus rapide que ce que ses disques pourraient jamais écrire. Ce résultat peut être mathématiquement correct pour la charge logique mais inutile pour une archive photo ou une sauvegarde chiffrée. Les erreurs courantes des benchmarks de stockage incluent des données de test très compressibles, des lectures en cache, des écritures non vidées et l'absence de comparaison du débit applicatif avec l'activité du périphérique.

Un test NAS domestique significatif utilise le même matériel, jeu de données, chemin client et charge de fond avec la compression activée et désactivée. Il enregistre le débit logique, les octets physiques de l'appareil, l'utilisation CPU, le ratio de compression et la latence d'écriture. Pour les charges synchrones ou multi-clients, la latence en percentiles est plus informative qu'un seul pic en MB/s car les courts arrêts peuvent être masqués dans une moyenne élevée.

L'interprétation finale est conditionnelle. Si les écritures physiques chutent fortement tandis que le CPU reste sous saturation, la compression agit comme un amplificateur de débit. Si le ratio reste proche de 1:1 et que le CPU ou la latence augmente, c'est surtout un travail supplémentaire. Si le réseau est déjà la limite, le stockage peut devenir plus efficace sans que la copie client ne se termine plus vite.

Questions fréquemment posées

La compression du système de fichiers ralentit-elle toujours les écritures NAS ?

Non. Elle peut augmenter le débit d'écriture logique lorsque les données compressibles et un goulot d'étranglement de stockage permettent à l'I/O économisé de compenser le coût CPU. Elle peut être neutre ou plus lente avec des données à haute entropie, une capacité CPU limitée, des niveaux de compression agressifs ou des écritures sensibles à la latence.

Quels fichiers NAS domestiques bénéficient le plus de la compression ?

Les journaux, textes, codes sources, données structurées répétées et disques virtuels partiellement vides sont des candidats courants. Les médias déjà compressés, archives et données chiffrées offrent généralement moins d'avantages, bien que le résultat réel dépende du contenu des blocs plutôt que du seul nom de fichier.

La compression du système de fichiers peut-elle réduire l'usure du SSD ?

Cela peut réduire les données hôtes écrites sur le SSD lorsque les blocs se compressent bien, ce qui peut diminuer une partie de la charge de travail de l'appareil. Cela n'élimine pas la collecte des déchets au niveau du contrôleur ni l'amplification des écritures, donc les gains d'endurance dépendent du système de fichiers, de la charge de travail, de l'espace libre et du firmware du SSD.