La preuve la plus solide de cette discussion n’est pas la capture d’écran de Files à 600 Mo/s, mais le test ultérieur du stockage direct. Un utilisateur dont la copie via l’interface Web de ZimaOS restait autour de 600–650 Mo/s a mesuré environ 2,3 Go/s en écriture directe avec dd et environ 2,2 Go/s en écriture avec fio. Cela exclut, pour cette machine, l’hypothèse selon laquelle le système d’exploitation limiterait globalement le NVMe aux performances du SATA III.
La conclusion la plus défendable est que le débit faible concernait le processus de copie interne de Files ou des effets liés à la charge de copie, comme les métadonnées, le copy-on-write de Btrfs, la mise en mémoire tampon ou les limites d’un seul thread, et non le chemin NVMe physique lui-même.
La source a reproduit la limite avec plusieurs chemins de copie
Dave a signalé un comportement similaire avec les configurations NVMe vers NVMe, NVMe vers RAID0, RAID0 vers un seul NVMe et les flux 10GbE. Un autre utilisateur a ensuite indiqué que la copie SMB de Windows vers ZimaOS pouvait atteindre le débit complet du 10GbE, tandis que la copie interne de Files restait autour de 650 Mo/s.
Les écritures directes avec dd ont atteint environ 2,3 Go/s
La source a utilisé dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progress et publié un résultat proche de 2,3 Go/s, bien supérieur au débit pratique du SATA III.
fio a également atteint environ 2,2 Go/s
L’exécution de fio présentée dans la source indiquait environ 2163 Mio/s, soit 2268 Mo/s, en écriture. Même si le moteur synchrone sélectionné limitait de fait la profondeur de file d’attente à un, le résultat prouvait tout de même que la pile de stockage pouvait dépasser plusieurs fois le débit de la copie Files.
Interprétez avec prudence le débit de lecture dd indiqué dans la source
La source a également mesuré environ 3,0 Go/s en lisant le fichier de test fraîchement créé vers /dev/null. Comme cette lecture n’utilisait pas explicitement les E/S directes et ne vidait pas le cache de pages, la mise en cache peut avoir influencé le résultat.
Une faible utilisation globale du processeur n’exclut pas un goulot d’étranglement sur un seul thread
Un processus de copie en espace utilisateur peut saturer un cœur tandis que l’utilisation totale du processeur reste modérée sur un système multicœur. Surveillez l’utilisation du processeur par thread et celle du disque pendant la copie lente dans Files.
Comparez le même fichier volumineux avec la ligne de commande et Files
Utilisez la même source, la même destination et le même fichier de test volumineux pour les copies avec Files et en ligne de commande, puis comparez les résultats à ceux d’un benchmark d’E/S directes non persistant. Cela permet de distinguer la surcharge de copie de l’interface et du backend des capacités brutes du périphérique.
Le nombre de fichiers et les métadonnées Btrfs peuvent modifier le débit réel des copies
Des milliers de petits fichiers nécessitent des opérations répétées sur les métadonnées, et le comportement de copy-on-write de Btrfs peut modifier le coût d’une copie interne.
Ne présentez pas cela comme une limitation universelle actuelle de ZimaOS
La source fournit des preuves solides d’un goulot d’étranglement historique dans Files et les copies internes sur plusieurs systèmes. Elle ne démontre pas que ZimaOS 1.7.1 présente encore exactement la même limite sur toutes les combinaisons de matériel et de systèmes de fichiers.
Une copie interne peut lire et écrire simultanément sur le même stockage
Si la source et la destination se trouvent sur le même NVMe physique ou le même pool RAID, le disque doit traiter les lectures et les écritures simultanément. Le débit de copie affiché n’est donc pas comparable à celui d’un benchmark d’écriture séquentielle unidirectionnelle.
Notez les périphériques physiques source et destination avant de comparer les résultats. « Copie interne » décrit le chemin logiciel, pas nécessairement deux SSD indépendants.
Vérifiez la largeur et la génération du lien PCIe avant de comparer les chiffres annoncés
Un NVMe haut de gamme peut être limité par un lien PCIe x1/x2, une génération plus ancienne, un partage de lignes avec le chipset ou un câblage de la plateforme différent de ce que laisse penser la taille physique du connecteur. Un benchmark brut atteignant plus de 2 Go/s exclut déjà une limite à 600 Mo/s, mais le débit peut rester inférieur au maximum indiqué par le fabricant du SSD pour des raisons légitimes liées à la topologie.
Les copies prolongées peuvent déclencher des limites thermiques ou liées au cache SLC du SSD
Les benchmarks courts et les copies de fichiers longues sollicitent les SSD différemment. Un disque peut démarrer très rapidement, puis ralentir lorsque son cache pseudo-SLC est rempli ou que sa température augmente. Surveillez la température du NVMe et le débit soutenu sur une période suffisamment longue avant d’attribuer chaque baisse à Files.
Le cache de pages peut faire paraître certains tests plus rapides que le périphérique
Le résultat d’écriture directe de la source constitue une preuve solide, car il utilisait les E/S directes. Les tests de lecture effectués immédiatement après l’écriture peuvent être influencés par le cache mémoire, sauf si le benchmark le désactive explicitement.
Pour obtenir des comparaisons reproductibles, utilisez une configuration de benchmark indiquant si les E/S directes sont activées et définissez une taille de fichier suffisamment grande pour réduire les effets du cache.
Testez à nouveau le processus Files actuel avant de considérer 600 Mo/s comme une limite fixe du produit
La discussion couvre des versions de ZimaOS antérieures à la version actuelle. Si Files semble toujours limité aujourd’hui, reproduisez le problème avec le même fichier volumineux, la même source, la même destination et une comparaison actuelle avec la ligne de commande et les E/S directes. Vous obtiendrez ainsi des preuves exploitables au lieu de perpétuer indéfiniment une ancienne limite chiffrée.
FAQ sur la vitesse du NVMe
La source a-t-elle prouvé que ZimaOS limite le NVMe à la vitesse du SATA ?
Non. Les écritures directes avec dd et fio ont dépassé 2 Go/s sur le même système.
Qu’est-ce qui était le plus probablement en cause selon la source ?
Le processus de copie interne de l’interface Web ou du gestionnaire de fichiers, ou la surcharge liée à la charge de travail, plutôt que le périphérique NVMe lui-même.
Faut-il considérer le résultat de lecture dd du fichier fraîchement écrit comme la vitesse réelle du disque ?
Pas nécessairement. Sans lecture directe ni contrôle du cache, le cache de pages peut influencer le résultat.
