La evidencia más sólida de este hilo no es la captura de Archivos a 600 MB/s, sino la prueba posterior de almacenamiento directo. Un usuario cuya copia en la interfaz web de ZimaOS se mantenía alrededor de 600–650 MB/s midió aproximadamente 2,3 GB/s de escrituras directas con dd y cerca de 2,2 GB/s con fio. Eso descarta, para ese equipo, la explicación de que NVMe esté limitado a SATA III en todo el sistema operativo.
La conclusión más defendible es que la cifra baja correspondía al flujo de copia interno de Archivos o a efectos propios de la carga de copia, como los metadatos, CoW de Btrfs, el almacenamiento en búfer o los límites de un solo hilo, y no a la ruta física NVMe en sí.
La fuente reprodujo el límite en varias rutas de copia
Dave informó de un comportamiento similar con NVMe a NVMe, NVMe a RAID0, RAID0 a un NVMe individual y flujos de trabajo mediante 10GbE. Más tarde, otro usuario indicó que la transferencia de Windows a ZimaOS mediante SMB podía alcanzar la velocidad completa de 10GbE, mientras que la copia interna de Archivos seguía alrededor de 650 MB/s.
Las escrituras directas con dd alcanzaron aproximadamente 2,3 GB/s
La fuente utilizó dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progress y publicó un resultado cercano a 2,3 GB/s, muy por encima del rendimiento práctico de SATA III.
fio también alcanzó aproximadamente 2,2 GB/s
La ejecución de fio de la fuente informó de aproximadamente 2163 MiB/s / 2268 MB/s en escrituras. Aunque el motor síncrono seleccionado limitaba en la práctica la profundidad de cola a uno, el resultado demostró que la pila de almacenamiento podía superar varias veces la cifra de la copia de Archivos.
Interpreta con cuidado la cifra de lectura de dd de la fuente
La fuente también midió alrededor de 3,0 GB/s al leer el archivo de prueba recién escrito en /dev/null. Como esa lectura no utilizó explícitamente E/S directa ni vació la caché de páginas, la caché puede influir en la cifra.
Un uso total bajo de la CPU no descarta un cuello de botella de un solo hilo
Un flujo de copia en el espacio de usuario puede saturar un núcleo mientras el uso total de la CPU sigue siendo moderado en un sistema con muchos núcleos. Supervisa el uso de la CPU por hilo y la utilización del disco durante la copia lenta de Archivos.
Compara el mismo archivo grande mediante la CLI y Archivos
Utiliza el mismo origen, destino y archivo de prueba grande para las copias con Archivos y con la CLI; después, compara los resultados con una prueba de E/S directa desechable. Así se separan los costes de copia de la interfaz o del backend de la capacidad sin procesar del dispositivo.
La cantidad de archivos y los metadatos de Btrfs pueden cambiar la velocidad de copia real
Miles de archivos pequeños requieren operaciones de metadatos repetidas, y el comportamiento de copia sobre escritura de Btrfs puede cambiar el coste de una copia interna.
No lo consideres una limitación universal actual de ZimaOS
La fuente aporta pruebas sólidas de un cuello de botella histórico en Archivos o en la copia interna en varios sistemas. No demuestra que el ZimaOS 1.7.1 actual siga teniendo exactamente el mismo límite en todas las combinaciones de hardware y sistemas de archivos.
Una copia interna puede leer y escribir simultáneamente en el mismo almacenamiento
Si el origen y el destino están en el mismo NVMe físico o en el mismo grupo RAID, la unidad debe atender lecturas y escrituras al mismo tiempo. Por tanto, el rendimiento visible de la copia no es comparable con una prueba de escritura secuencial unidireccional.
Registra los dispositivos físicos de origen y destino antes de comparar resultados. «Copia interna» describe la ruta de software, no necesariamente dos SSD independientes.
Comprueba el ancho de enlace y la generación de PCIe antes de comparar las cifras comerciales
Un NVMe de gama alta puede estar limitado por un enlace PCIe x1/x2, una generación anterior, el reparto de líneas del chipset o una ranura de la plataforma conectada de forma distinta a lo que su tamaño físico indica. Una prueba sin procesar que alcance más de 2 GB/s ya descarta un límite de 600 MB/s, pero todavía puede quedar por debajo de la velocidad máxima especificada para el SSD en un equipo de escritorio por motivos legítimos de topología.
Las copias sostenidas pueden activar límites térmicos o de caché SLC del SSD
Las pruebas breves y las copias de archivos largas ejercitan los SSD de forma diferente. Una unidad puede comenzar a gran velocidad y después disminuir cuando se llena su caché pseudo-SLC o aumenta la temperatura. Supervisa la temperatura del NVMe y el rendimiento sostenido durante un intervalo suficientemente largo antes de atribuir cada descenso a Archivos.
La caché de páginas puede hacer que algunas pruebas parezcan más rápidas que el dispositivo
El resultado de escritura directa de la fuente es una prueba sólida porque utilizó E/S directa. Las pruebas de lectura realizadas inmediatamente después de escribir pueden verse influidas por la caché de memoria, a menos que la prueba la omita explícitamente.
Para obtener comparaciones reproducibles, utiliza una configuración de prueba que indique si la E/S directa está activada y mantén el archivo de prueba lo bastante grande como para reducir la distorsión de la caché.
Vuelve a probar el flujo actual de Archivos antes de considerar 600 MB/s un límite fijo del producto
El hilo abarca versiones de ZimaOS anteriores a la versión actual. Si Archivos sigue pareciendo limitado hoy, reprodúcelo con el mismo archivo grande, el mismo origen y destino, y una comparación actual con la CLI y con E/S directa. Así obtendrás pruebas prácticas en lugar de arrastrar indefinidamente un límite numérico antiguo.
Preguntas frecuentes sobre la velocidad de NVMe
¿La fuente demostró que ZimaOS limita NVMe a la velocidad de SATA?
No. Las escrituras directas con dd y fio superaron los 2 GB/s en el mismo sistema.
¿Qué señaló con mayor claridad la fuente?
El flujo de copia interno de la interfaz web o del gestor de archivos, o los costes de la carga de trabajo, más que el propio dispositivo NVMe.
¿Debe considerarse el resultado de lectura de dd del archivo recién escrito como la velocidad pura del disco?
No necesariamente. Sin E/S de lectura directa ni control de la caché, la caché de páginas puede influir en el resultado.
