Une copie dans ZimaOS Files affichant environ 600–650 Mo/s ne prouve pas que le périphérique NVMe lui-même est limité à une vitesse de type SATA. Le guide communautaire de la source distingue correctement le débit brut du stockage du débit du flux de travail de copie de fichiers. Un gestionnaire de fichiers basé sur un navigateur peut ajouter la gestion des métadonnées, le suivi de la progression, des mécanismes de sécurité, des copies effectuées en espace utilisateur, la surcharge du système de fichiers et des opérations fichier par fichier, autant d’éléments qu’un benchmark direct ne mesure pas.
L’approche la plus utile est comparative : testez le même stockage avec une charge volumineuse d’E/S séquentielles directes, puis copiez le même fichier volumineux via l’interface en ligne de commande et via Files. Si les tests bruts et directs atteignent plusieurs Go/s tandis que la copie dans l’interface reste proche de 600 Mo/s, le goulot d’étranglement se situe probablement en amont du périphérique NVMe.
Un seul chiffre de copie de fichier ne constitue pas un benchmark NVMe
La vitesse de copie interne dépend des éléments suivants :
- la présence de la source et de la destination sur le même périphérique ou sur des périphériques différents ;
- le type de système de fichiers ;
- le comportement de la copie en écriture ;
- la taille et le nombre de fichiers ;
- la charge du processeur ;
- le cache de pages ;
- l’implémentation de la copie.
Un résultat de 600 Mo/s peut être excellent pour un flux de travail et médiocre pour un autre.
Commencez par un fichier de test séquentiel volumineux
Les fichiers volumineux réduisent le bruit lié aux métadonnées et facilitent l’interprétation du débit soutenu. La source utilisait un fichier de 10 Go afin que la charge dure suffisamment longtemps pour être observée.
Avant de créer un fichier de test volumineux, vérifiez que le stockage cible dispose de suffisamment d’espace libre. Un benchmark qui remplit le disque système ou de données peut provoquer une défaillance différente.
La source utilisait dd avec des écritures directes
Le guide de la communauté proposait :
dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progressoflag=direct réduit les effets du cache de pages lors de l’écriture. C’est utile pour une vérification sommaire des écritures séquentielles.
Ne supposez pas que chaque compilation, périphérique ou système de fichiers accepte exactement le même comportement pour la taille de bloc ou les E/S directes.
Interprétez avec plus de prudence le test de lecture dd de la source
La source lisait ensuite le fichier vers /dev/null. Sans option de lecture en E/S directe ni contrôle du cache, un fichier récent peut être partiellement servi depuis le cache de pages et exagérer la vitesse de lecture apparente.
Pour comparer efficacement des stockages, privilégiez un outil ou une configuration qui utilise explicitement les E/S directes dans les deux sens, ou assurez-vous de bien comprendre les effets de la mise en cache.
fio est un meilleur benchmark de stockage contrôlé
L’exemple d’écriture soutenue de la source utilisait :
fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reportingIl s’agit toujours de conseils de la communauté, mais la forme du benchmark est plus claire : taille de test explicite, écritures séquentielles, profondeur de file d’attente, E/S directes, durée d’exécution et résultats regroupés.
Ne lancez jamais une tâche fio destructive sur un périphérique brut contenant des données réelles. Utilisez un fichier de test jetable sur un système de fichiers, sauf si vous comprenez parfaitement les conséquences.
Comparez l’interface graphique et la ligne de commande avec le même jeu de données
Le conseil méthodologique le plus important de la source est d’utiliser le même fichier volumineux pour les deux :
- une copie en ligne de commande ;
- une copie avec Fichiers de ZimaOS.
Si le jeu de données, la source, la destination et le système de fichiers sont identiques, la différence reflète plus directement le pipeline de copie.
Les petits fichiers peuvent être considérablement plus lents
Des milliers de photos, de fichiers de projet, de miniatures ou d’éléments AppData nécessitent de nombreuses opérations répétées d’ouverture, de création, de traitement des métadonnées et de calcul de sommes de contrôle. Le débit de transfert global peut être bien inférieur à celui d’un seul film ou fichier ISO volumineux, même sur un NVMe très rapide.
La copie à la volée de Btrfs et le traitement des métadonnées peuvent ajouter une surcharge supplémentaire selon l’opération exacte.
Surveillez le processeur et les entrées-sorties pendant l’exécution de la copie lente
La source recommande de surveiller simultanément l’utilisation du disque et celle du processeur. L’objectif est de déterminer si :
- le disque est saturé ;
- un seul cœur du processeur constitue le goulot d’étranglement ;
- un autre processus accapare les entrées-sorties ;
- le pipeline de copie attend au lieu de solliciter le stockage ;
Cela est plus instructif que de ne citer que la valeur de la barre de progression de Fichiers.
La vitesse du NVMe dépend aussi des lignes PCIe et du périphérique
Même un NVMe en bon état peut fonctionner en dessous de sa valeur annoncée si :
- le logement est en PCIe x1/x2 plutôt qu’en x4 ;
- la plateforme utilise le PCIe Gen 3 plutôt que le Gen 4 ;
- le SSD subit une limitation thermique ;
- le contrôleur partage les lignes ;
- Le cache SLC est épuisé pendant les écritures prolongées.
Un véritable test de performances doit être comparé à la topologie matérielle, et non à l’attente générique selon laquelle « NVMe = 7 Go/s ».
Les guides de transfert actuels d’IceWhale distinguent également l’interface utilisateur des chemins de transfert plus rapides
Le guide Thunderbolt de ZimaCube d’IceWhale a historiquement montré que le chemin de transfert via l’interface utilisateur de ZimaOS était plus lent qu’un chemin direct Samba/Thunderbolt, ce qui confirme le principe général selon lequel l’interface de gestion des fichiers n’est pas identique au débit brut du stockage ou du réseau.
Utilisez la checklist actuelle de dépannage des transferts de ZimaOS pour effectuer les vérifications prises en charge côté réseau.
Supprimer les fichiers de test une fois terminé
Volumineux dd/fio Les fichiers peuvent rapidement occuper des dizaines de gigaoctets. Supprimez les fichiers de test connus après avoir relevé les résultats, puis vérifiez l’espace libre.
FAQ sur les tests de performances NVMe
Un débit de 600 Mo/s dans Fichiers de ZimaOS prouve-t-il que le NVMe est limité à la vitesse du SATA ?
Non. Cela mesure ce flux de copie, et non les capacités brutes du NVMe.
Pourquoi une lecture avec dd peut-elle sembler irréalistement rapide ?
Un fichier écrit récemment peut être servi en partie depuis le cache de pages, sauf si le test de lecture évite explicitement la mise en cache.
Quelle est la meilleure comparaison pour le pipeline de copie de l’interface graphique ?
Utilisez la même source et la même destination, ainsi que le même jeu de données volumineux, dans l’interface en ligne de commande et dans l’application Fichiers, puis comparez les résultats tout en surveillant l’utilisation du processeur et les entrées-sorties du stockage.
