Solución de la comunidad

La copia de NVMe en ZimaOS parece limitada a 600 MB/s: prueba el almacenamiento con dd, fio y el mismo conjunto de datos

A January 2026 community benchmarking guide arguing that a ~600 MB/s ZimaOS Files copy does not prove NVMe is limited to SATA speed. It recommends comparing the same workload through dd, fio, CLI copy, and GUI copy while watching CPU and I/O. The commands are community guidance, not IceWhale's official benchmark procedure.

Que una copia en Files de ZimaOS informe aproximadamente 600–650 MB/s no demuestra que el dispositivo NVMe esté limitado a la velocidad de SATA. La guía comunitaria de la fuente distingue correctamente entre el rendimiento del almacenamiento sin formato y el rendimiento del flujo de trabajo de copia de archivos. Un administrador de archivos basado en navegador puede añadir metadatos, seguimiento del progreso, lógica de seguridad, copias en el espacio de usuario, sobrecarga del sistema de archivos y operaciones por archivo que una prueba directa no mide.

El enfoque más útil es comparativo: prueba el mismo almacenamiento con una carga grande de E/S directa secuencial y, después, copia el mismo archivo grande mediante la CLI y Files. Si las pruebas sin formato/directas alcanzan varios GB/s mientras la copia mediante la interfaz gráfica sigue cerca de 600 MB/s, es probable que el cuello de botella esté por encima del dispositivo NVMe.

Una sola cifra de copia de archivos no es una prueba comparativa de NVMe

La velocidad de copia interna depende de:

  • que el origen y el destino sean el mismo dispositivo o dispositivos diferentes;
  • tipo de sistema de archivos;
  • comportamiento de copia al escribir;
  • tamaño y cantidad de archivos;
  • carga de la CPU;
  • caché de páginas;
  • la implementación de copia.

Un resultado de 600 MB/s puede ser excelente para un flujo de trabajo y deficiente para otro.

Comienza con un archivo de prueba secuencial grande

Los archivos grandes reducen el ruido de los metadatos y facilitan la interpretación del rendimiento sostenido. La fuente utilizó un archivo de 10 GB para que la carga durara lo suficiente como para observarla.

Antes de crear un archivo de prueba grande, verifica que el almacenamiento de destino tenga suficiente espacio libre. Una prueba que llene el disco del sistema o de datos puede provocar un fallo diferente.

La fuente utilizó dd con escrituras directas

La guía de la comunidad proponía:

dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progress

oflag=direct reduce los efectos de la caché de páginas en la ruta de escritura. Esto resulta útil para una comprobación aproximada de la escritura secuencial.

No asumas que todas las compilaciones, dispositivos o sistemas de archivos aceptan de la misma manera el tamaño de bloque o el comportamiento de la E/S directa.

Interpretar con más cuidado la prueba de lectura con dd de la fuente

A continuación, la fuente leyó el archivo para /dev/null. Sin una opción de lectura de E/S directa o un control de la caché, un archivo reciente puede servirse parcialmente desde la caché de páginas y exagerar la velocidad de lectura aparente.

Para comparar el almacenamiento de forma fiable, es preferible usar una herramienta o configuración que emplee explícitamente E/S directa en ambas direcciones, o asegurarse de comprender los efectos de la caché.

fio es una mejor herramienta para una prueba de almacenamiento controlada

El ejemplo de escritura sostenida de la fuente utilizaba:

fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reporting

Esto sigue siendo una guía de la comunidad, pero tiene una estructura de referencia más clara: tamaño de prueba explícito, escrituras secuenciales, profundidad de cola, E/S directa, duración y resultados agrupados.

Nunca dirijas un trabajo destructivo de fio a un dispositivo sin formato que contenga datos reales. Usa un archivo de prueba desechable en un sistema de archivos, a menos que comprendas completamente las consecuencias.

Compara la interfaz gráfica y la CLI con el mismo conjunto de datos

El consejo metodológico más importante de la fuente es usar el mismo archivo grande para ambas:

  • una copia mediante la CLI;
  • una copia con ZimaOS Files.

Si el conjunto de datos, el origen, el destino y el sistema de archivos son idénticos, la diferencia refleja más directamente el proceso de copia.

Los archivos pequeños pueden ser mucho más lentos

Miles de fotos, archivos de proyectos, miniaturas o entradas de AppData requieren operaciones repetidas de apertura, creación, metadatos y sumas de comprobación. La velocidad de transferencia agregada puede caer muy por debajo de la de una sola película grande o una imagen ISO, incluso en una unidad NVMe muy rápida.

La copia en escritura de Btrfs y el comportamiento de los metadatos pueden añadir más sobrecarga según la operación exacta.

Supervisa la CPU y la E/S mientras se ejecuta la copia lenta

La fuente recomienda observar al mismo tiempo la utilización del disco y la CPU. El objetivo es determinar si:

  • el disco está saturado;
  • un núcleo de la CPU es el cuello de botella;
  • otro proceso está compitiendo por la E/S;
  • el proceso de copia está esperando en lugar de aprovechar al máximo el almacenamiento.

Esto es más informativo que citar únicamente la cifra de la barra de progreso de Files.

La velocidad de NVMe también depende de las líneas PCIe y del dispositivo

Incluso una unidad NVMe en buen estado puede funcionar por debajo de su cifra anunciada si:

  • la ranura es PCIe x1/x2 en lugar de x4;
  • la plataforma es PCIe Gen 3 en lugar de Gen 4;
  • la SSD está sufriendo limitación térmica;
  • el controlador comparte líneas;
  • La caché SLC se agota durante las escrituras sostenidas.

Un punto de referencia real debe compararse con la topología del hardware, no con una expectativa genérica de «NVMe = 7 GB/s».

Las guías de transferencia actuales de IceWhale también separan las rutas de la interfaz y de transferencia más rápidas

La guía de IceWhale sobre Thunderbolt para ZimaCube ha mostrado históricamente que la ruta de transferencia de la interfaz de ZimaOS funciona más lentamente que una ruta directa mediante Samba/Thunderbolt, lo que refuerza la idea general de que la interfaz de archivos no es idéntica al rendimiento bruto de almacenamiento o de red.

Usa la lista de comprobación actual para solucionar problemas de transferencia de ZimaOS para realizar las comprobaciones compatibles del lado de la red.

Eliminar los archivos de prueba al terminar

Grande dd/fio Los archivos pueden consumir rápidamente decenas de gigabytes. Elimina los archivos de prueba conocidos después de registrar los resultados y verifica el espacio libre posteriormente.

Preguntas frecuentes sobre las pruebas de rendimiento de NVMe

¿Que ZimaOS Files alcance 600 MB/s demuestra que la unidad NVMe está limitada a la velocidad SATA?

No. Mide ese flujo de trabajo de copia, no la capacidad bruta de NVMe.

¿Por qué una lectura con dd puede parecer irrealmente rápida?

Un archivo escrito recientemente puede servirse parcialmente desde la caché de páginas, a menos que la prueba de lectura evite explícitamente el almacenamiento en caché.

¿Cuál es la mejor comparación para el proceso de copia de la interfaz gráfica?

Usa la misma fuente/destino y el mismo conjunto de datos grande tanto en la CLI como en Files, y luego compara mientras supervisas la CPU y la E/S del almacenamiento.