XFS frente a EXT4 en servidores NVMe: pruebas de rendimiento y comparación práctica

Comparo XFS EXT4 en servidores NVMe, basándome en pruebas de rendimiento actuales y datos prácticos, y te mostraré en qué casos cada sistema de archivos ofrece un rendimiento superior medible. Para ello, me centraré en el rendimiento, las latencias y las cargas de trabajo reales, para que puedas aprovechar el rendimiento de NVMe en el servidor de forma específica.

Puntos centrales

Para empezar, resumiré brevemente las conclusiones más importantes antes de entrar en detalles, pruebas comparativas y ajustes.

• E/S aleatoria: Ambos están muy igualados; EXT4 ofrece un rendimiento ligeramente superior, mientras que XFS presenta latencias más uniformes.
• Secuencial: XFS suele estar a la cabeza con archivos grandes, seguido de cerca por EXT4, que ofrece velocidades sólidas.
• Metadatos: EXT4 ofrece algunas pequeñas ventajas; XFS, tiempos de respuesta constantes.
• Aplicaciones: En las encuestas, están muy igualados, con diferencias que se sitúan en un porcentaje muy bajo.
• Sintonización: El núcleo, el programador, el nivel de E/S, el espacio libre y las opciones de montaje marcan la diferencia.

XFS y EXT4 en NVMe: análisis técnico

EXT4 se considera un estándar de Linux de probada eficacia y ofrece un rendimiento muy fiable Es la base y sirve de referencia en muchas comparativas. XFS está diseñado para archivos de gran tamaño, alto nivel de paralelismo y flujos de datos secuenciales, y es capaz de aprovechar muy bien el rendimiento de NVMe. En el hardware moderno, las diferencias se reducen, ya que ambos sistemas de archivos han madurado a lo largo de los años y las nuevas versiones del núcleo optimizan aún más la pila de NVMe. En las cargas de trabajo cotidianas, a menudo son los perfiles de carga los que marcan la diferencia: si hay muchos accesos pequeños y aleatorios muy próximos entre sí, las grandes transferencias secuenciales suelen favorecer a XFS. Por lo tanto, quien tenga que tomar una decisión debería conocer su perfil de E/S y no basarse únicamente en Clasificaciones mirar.

E/S aleatoria en NVMe: bloques pequeños, alto nivel de paralelismo

En el caso de los accesos 4K y 8K, ambos sistemas de archivos ofrecen IOPS a un nivel muy similares Nivel, a menudo con una diferencia de tan solo unos pocos puntos porcentuales. EXT4 muestra, en algunas mediciones, valores medios ligeramente superiores en la escritura aleatoria, lo que puede apreciarse en escenarios similares a OLTP. XFS, por su parte, destaca por unas latencias más uniformes y menos fluctuaciones a lo largo de períodos de ejecución más prolongados, lo que favorece unos tiempos de respuesta predecibles con cargas mixtas. En entornos de producción, las cachés, la lógica de las aplicaciones y las rutas de red suelen enmascarar estas sutiles diferencias. Por ello, cobran mayor importancia otros parámetros de ajuste, como la caché del búfer, la estrategia WAL o la profundidad de E/S (fuente: 1, 4, 7).

Transferencias secuenciales: cómo mover archivos grandes de forma eficiente

En el caso de bloques del tamaño de un MB y flujos largos y secuenciales, XFS suele llevar la delantera, ya que la disposición de los extents permite gestionar de forma eficiente los archivos grandes gestionado. Las ventanas de copia de seguridad, las tareas de archivado y los puntos de control secuenciales se benefician notablemente de ello, especialmente en NVMe PCIe 4.0/5.0. EXT4 se mantiene muy cerca y ofrece velocidades muy buenas, que apenas suponen una limitación en muchas configuraciones. Cuanto más largo es el flujo y cuanto mayor es el archivo, más claramente se decanta la ventaja hacia XFS. Mi breve Comparación de resultados con cargas de trabajo típicas de servidor (fuentes: 4, 5, 9).

Operaciones con metadatos: muchos archivos pequeños

Las cargas de trabajo con numerosas operaciones de archivos suponen un reto para las rutas de metadatos y dan lugar a diferencias en cuanto al bloqueo y el registro en diario. Luz. En algunas pruebas, EXT4 se sitúa ligeramente por delante en la creación y eliminación rápida de muchos archivos pequeños. Por su parte, XFS destaca por sus latencias constantes, lo que lo convierte en una opción fiable para registros, cachés y directorios de compilación. En comparación con otros sistemas de archivos, ambos muestran una gestión madura y patrones de respuesta predecibles. Quien maneje grandes cantidades de archivos pequeños debería tener en cuenta las opciones de montaje y realizar pruebas prácticas durante períodos prolongados (fuentes: 1, 7, 13).

Resumen de las pruebas comparativas en cifras

A continuación resumo de forma concisa las siguientes tendencias para que puedas identificar rápidamente los patrones típicos reconocer. E/S aleatoria con bloques pequeños: las diferencias suelen ser mínimas, a menudo en el rango de ±3–5 % en IOPS. Secuencial con bloques grandes: XFS suele estar por delante, especialmente en flujos largos y archivos grandes. Pruebas con gran cantidad de metadatos: en algunos casos, ligera ventaja de EXT4; XFS presenta latencias uniformes. En escenarios analíticos, ambos sistemas de archivos suelen alcanzar entre 80 y 85 % del rendimiento teórico de NVMe, dependiendo del núcleo, el controlador y el firmware del controlador (fuentes: 1, 3, 4, 5, 10).

Escenario	Tendencia	Ventaja típica	Nota
E/S aleatoria (4K/8K)	Muy estrecho	EXT4 ofrece un rendimiento ligeramente superior	XFS suele ofrecer latencias más uniformes
Secuencial (≥1 MB)	XFS a la cabeza	Mayor rendimiento con archivos de gran tamaño	Las transmisiones largas potencian el efecto
Operaciones con metadatos	Codo a codo	EXT4 es, en algunos casos, más rápido en las operaciones de creación y eliminación	XFS se mantiene estable con una carga mixta
Bases de datos (OLTP)	Muy estrecho	EXT4: TPS ligeramente superior	XFS: tiempos de respuesta más uniformes
Análisis y generación de informes	Eng	XFS en escaneos de gran tamaño	Ambos utilizan entre el 80 y el 85 % de % del HW

Pruebas de rendimiento orientadas a aplicaciones: bases de datos y carga mixta

En las pruebas con PostgreSQL o MySQL, observo una reñida competencia que viene determinada por los perfiles de latencia, las estrategias WAL y la configuración de la caché de búfer vive. EXT4 ofrece, en algunos casos, un ligero aumento en el número de transacciones por segundo en condiciones de alto paralelismo. XFS destaca por sus tiempos de respuesta estables, lo que puede suavizar las latencias residuales en las API críticas. Las diferencias son lo suficientemente pequeñas como para que el ajuste de la base de datos resulte más eficaz que el mero cambio de sistema de archivos. Por lo tanto, quien tome la decisión debería medir las pruebas de rendimiento típicas de la carga de trabajo y observar atentamente las métricas de la aplicación (fuentes: 2, 3, 9).

Versión del núcleo, modelos NVMe y su influencia

Los kernels más recientes de Linux de las series 5.x y 6.x reducen las latencias y aumentan el rendimiento, lo que beneficia a ambos sistemas de archivos en unidades NVMe de alta velocidad y elimina los cuellos de botella en la pila de E/S. reduce. Los SSD empresariales con una gran caché de DRAM y protección contra cortes de corriente disimulan aún más las diferencias, ya que el controlador y el firmware limitan el rendimiento antes de que el sistema de archivos entre en juego. Los NVMe de consumo más económicos muestran esta diferencia con mayor claridad, aunque en el día a día suelen estar muy próximos entre sí. PCIe 4.0/5.0 aumenta el margen de rendimiento, lo que hace que las ventajas secuenciales de XFS sean más evidentes. Por lo tanto, las actualizaciones del núcleo, el firmware NVMe y las versiones de controladores optimizadas ofrecen beneficios cuantificables (fuentes: 1, 5, 10, 11).

Optimización de NVMe: programador, profundidad de E/S, espacio libre

A menudo empiezo con un programador sencillo como ninguno o «mq-deadline» y ajusto la profundidad de E/S (I/O-Depth) según cada carga de trabajo para llenar las colas de forma óptima. Una profundidad demasiado alta genera picos de latencia, mientras que una demasiado baja desperdicia recursos paralelos. Prever un espacio libre de 15-20 % reduce la fragmentación y mantiene la rapidez de las asignaciones. En el caso de XFS, analizo la distribución en grupos de asignación, ya que estos influyen de manera decisiva en el paralelismo del sistema de archivos; un buen tema de partida son los Grupos de asignación de XFS. Mido cada cambio mediante una comparación A/B, para que los efectos sean trazables y no se pase por alto ningún empeoramiento.

Aprovechar las opciones de montaje de forma específica

Las opciones de montaje influyen en el registro en diario, los intervalos de confirmación y las rutas de escritura, y pueden afectar a la latencia y al rendimiento notable Ajustar. EXT4 ofrece opciones útiles relacionadas con el modo de diario y los tiempos de confirmación, mientras que XFS ofrece opciones para los búferes de registro y los parámetros de inodos. Adapto estos ajustes en función del perfil de carga y documento cada cambio. Quien quiera profundizar más, encontrará indicaciones concisas sobre los parámetros más útiles en los Opciones de montaje de EXT4. Es importante comprobar siempre cada ajuste de montaje con cargas de trabajo reales, y no solo con pruebas sintéticas.

Práctica del alojamiento web: selección en función de la carga de trabajo

Para aplicaciones web clásicas con CMS y tiendas online, EXT4 ofrece una solución fiable Base, ya que predominan los archivos pequeños y los patrones mixtos de E/S. Las bases de datos con alto grado de paralelismo funcionan muy bien en ambos sistemas de archivos; mi decisión se basa en la experiencia previa, la configuración de la supervisión y el plan de copias de seguridad. Los grandes flujos de datos secuenciales en copias de seguridad y archivos favorecen a XFS, lo que agiliza las ventanas de transferencia. Las cargas de trabajo de análisis también se benefician de la gestión de grandes escaneos por parte de XFS, mientras que los perfiles mixtos a menudo apenas muestran diferencias. Quien tenga dudas, puede configurar un sistema de prueba y realizar mediciones en función de las cargas diarias más importantes.

Estrategia de pruebas: realista y cuantificable

Combino pruebas cortas de rendimiento máximo con carreras largas de resistencia para poder evaluar tanto los valores máximos como la variabilidad y los efectos del envejecimiento. véase. En lugar de limitarme a herramientas sintéticas, utilizo copias de bases de datos productivas, archivos de registro típicos y tareas reales de importación y exportación. La monitorización con iostat, perf y métricas de aplicaciones se ejecuta constantemente, lo que me permite demostrar de forma inequívoca las correlaciones. Repito las pruebas tras las actualizaciones del núcleo o los cambios de firmware para detectar a tiempo posibles regresiones. De este modo, se comprueba si XFS o EXT4 ofrecen en el entorno propio el mejor equilibrio entre rendimiento, latencia y previsibilidad (fuente: 1).

Registro en diario, barreras y semántica de sincronización en NVMe

Los detalles del registro influyen en los picos de latencia y en el comportamiento de recuperación. EXT4 utiliza de forma predeterminada datos=ordenados y escribe metadatos en el diario, mientras que los datos de trabajo se guardan de forma permanente antes de la confirmación. Quien necesite la máxima velocidad de escritura asumiendo un riesgo aceptable, puede data=respuesta Hay que tenerlo en cuenta, aunque esto dificulta la reproducción de las partidas tras un fallo del sistema. Las versiones más recientes de EXT4 son compatibles con fast_commit, lo que agrupa numerosas transacciones pequeñas de metadatos y acorta los tiempos de confirmación. XFS mantiene su propio registro (diario), cuyo logbsize y logbufs influyen notablemente en el paralelismo y la latencia. En NVMe, Barreras de escritura Importante: sin la protección contra pérdidas de energía (PLP), las barreras deben permanecer activas para garantizar el reordenamiento del firmware del controlador. Con la PLP se pueden reducir las barreras de forma selectiva para acelerar las cargas que requieren muchas llamadas a fsync(); hay que sopesar siempre este cambio frente al riesgo que conlleva. Para aplicaciones con requisitos estrictos de durabilidad (por ejemplo, bases de datos), un comportamiento correcto de fsync() es más importante que unos pocos puntos porcentuales más de rendimiento.

TRIM/Descartar y comportamiento a largo plazo de NVMe

Influir en Flash Descartar/Recortar-Estrategias para un rendimiento de escritura sostenible. El «inline-discard» durante el montaje (discard/async_discard) reduce el trabajo en segundo plano del controlador, pero puede generar picos de latencia bajo carga. Periódico fstrimLas ejecuciones periódicas (por ejemplo, semanales) mantienen un rendimiento más constante en muchos entornos de producción y separan la liberación de bloques no utilizados de la ruta principal. XFS procesa los descartes de forma eficiente por lotes, mientras que EXT4 ofrece con descartar=asíncrono Una variante suave. Es importante que la operación «Discard» se propague correctamente a través de todas las capas (dm-crypt, LVM, MD-RAID, hipervisor). Si a largo plazo se mantienen libres entre 15 y 20 % de reserva, se reduce la recolección interna de basura: la fluctuación de la latencia disminuye y el rendimiento de escritura se mantiene más estable.

RAID, LVM y cifrado: cómo coordinar adecuadamente las capas

Antes de formatear, la geometría de bloques debe ser compatible con RAID/LVM. Para XFS, la elección correcta de sunit/swidth (Asignación-Alineación) la eficiencia de las transferencias secuenciales de gran volumen; en EXT4, esto lo hacen stride/stripe-width. Si la alineación es correcta, se minimizan los ciclos de lectura-modificación-escritura en el RAID. LVM-Thin y las instantáneas son prácticas, pero aumentan la latencia en las rutas de escritura; esto tiene mayor importancia en las cargas de trabajo aleatorias que en los escaneos puros. dm-crypt/LUKS Consume recursos de la CPU y puede limitar las IOPS en bloques pequeños; las modernas tecnologías AES-NI y ARM-Crypto ayudan, pero las latencias de cola suelen aumentar ligeramente. En el caso de los volúmenes cifrados, merece la pena reajustar la profundidad de E/S y las afinidades de cola, así como permitir explícitamente el descarte, siempre que las políticas de seguridad lo permitan.

CPU/NUMA, afinidad de interrupciones e io_uring: ajuste preciso de la latencia

NVMe se escala a través de varias colas de envío y finalización; quien Ubicación NUMA Ten en cuenta que esto reduce los saltos entre nodos. Las IRQ de NVMe y los hilos de trabajo de la aplicación deben ejecutarse en el mismo nodo NUMA en el que está asignada la memoria. En Linux, el «IRQ pinning» y la configuración personalizada rps/xps-Configuración para mantener la ruta de datos de forma local. Las cargas de trabajo modernas se benefician de io_uring (en lugar del AIO anterior), que reduce las llamadas al sistema y permite el envío por lotes. En las pruebas fio, esto se traduce en latencias más bajas con el mismo número de IOPS. Las profundidades de cola demasiado elevadas (iodepth) distorsionan, sin embargo, la distribución de la latencia; lo más recomendable es realizar pruebas escalonadas (por ejemplo, 1, 4, 16, 64) para identificar el punto óptimo para cada carga de trabajo.

Entornos de contenedores y máquinas virtuales: particularidades de la pila

En el ámbito de los contenedores (overlayfs), XFS fue durante mucho tiempo la opción estándar porque d_type que estaba disponible de forma fiable desde el principio y que los grandes conjuntos de capas se gestionaban de manera eficiente. Hoy en día, las implementaciones modernas de EXT4 ofrecen una estabilidad equivalente; las diferencias de rendimiento son mínimas y dependen más de overlayfs que del propio sistema de archivos. En las máquinas virtuales predominan las interfaces Virtio/NVMe y los modos de almacenamiento en caché del hipervisor: cache=none Además, O_DIRECT en el modo invitado reduce el doble almacenamiento en búfer. Es importante tener en cuenta Entrega de descartes y tamaños de sector uniformes (4K frente a 512e) para evitar la amplificación de escritura. Las plataformas basadas en instantáneas (p. ej., QCOW2, ZVOL) incorporan la técnica «copy-on-write»; la elección del sistema de archivos en el sistema invitado sigue siendo relevante, pero el backend del host suele llegar a sus límites antes que los propios XFS/EXT4.

Recuperación, coherencia y ventanas de mantenimiento

Ambos sistemas de archivos se consideran robustos, pero el Procedimientos de mantenimiento se diferencian. EXT4 se puede comprobar a fondo con e2fsck; en volúmenes muy grandes, esto lleva bastante tiempo si hay errores, pero se beneficia de mejoras incrementales (Fast-Commit acorta la reproducción de transacciones más pequeñas). XFS es en Coherencia en línea configurado; las comprobaciones en profundidad se ejecutan con xfs_repair, que en casos graves requiere mucha memoria RAM y puede llevar bastante tiempo si los árboles son muy grandes. Para sistemas en producción, merece la pena fsfreeze antes de las instantáneas de LVM/almacenamiento, para obtener copias de seguridad coherentes con las aplicaciones; además, las bases de datos deberían activar sus propios mecanismos de puntos de control y copias de seguridad. Quienes tengan SLA con RTO/RPO cortos deben planificar explícitamente pruebas de recuperación: esto desmonta mitos y muestra ventanas de inactividad realistas.

Aspectos relacionados con las prestaciones que van más allá del rendimiento bruto

El rendimiento no lo es todo. XFS ofrece ReflinkCopias basadas en - y «hooks» de deduplicación, lo que ahorra espacio de almacenamiento en imágenes de máquinas virtuales y grandes catálogos multimedia, y reduce los tiempos de copia. EXT4 destaca por su amplia compatibilidad con herramientas y sus valores predeterminados conservadores, que simplifican las implementaciones. Cuotas están disponibles en ambos entornos; XFS destaca por Proyecto-Cuotas para cuotas basadas en directorios en grandes estructuras multitenant. Opciones como noatime/relatime/lazytime Reducen notablemente la carga de escritura de metadatos. Quienes utilicen el cifrado por directorio o por archivo (fscrypt) deben tener en cuenta la ligera sobrecarga que supone en el caso de pequeños accesos aleatorios y disponer de reservas de CPU.

Cómo evitar errores de medición: errores típicos

Muchas de las supuestas diferencias entre FS son, en realidad, Artefactos de prueba. Los conjuntos de datos demasiado pequeños acaban en la caché de página y ocultan las diferencias; los conjuntos de datos deberían ser más grandes que la RAM disponible. La falta de un calentamiento Alteran los perfiles de escritura aleatoria en la memoria flash; del mismo modo, las tareas de mantenimiento que se ejecutan en paralelo (scrubs, rebuilds, fstrim) provocan valores atípicos. En las pruebas fio debe quedar claro si direct=1 Se comprueba si las fases de fsync() están configuradas de forma realista y si las combinaciones de lectura y escritura se ejecutan de forma intercalada o por fases. Para obtener resultados reproducibles se necesitan frecuencias de CPU fijas (sin reguladores de escalado agresivos), una carga de fondo constante y un aislamiento claro entre la prueba y la supervisión.

Lista de comprobación práctica: cómo proceder

• Aclarar el perfil de la carga de trabajo: Tamaños de bloque, relación lectura/escritura, presupuesto de latencia, comportamiento en ráfagas.
• Limpiar la pila: Comprobar el kernel, el firmware NVMe y las versiones de los controladores; comprobar la afinidad de IRQ y NUMA.
• Alinear la maquetación: Configurar correctamente la alineación RAID/LVM (sunit/swidth o stride/stripe-width).
• Probar las opciones de montaje: Barreras, intervalos de confirmación, noatime/relatime/lazytime; parámetros de registro de XFS.
• Calibrar la profundidad de E/S: Sopesar la latencia frente al rendimiento y encontrar el punto óptimo para cada aplicación.
• Prever espacio libre: 15–20 % Reserva para latencias uniformes y menor fragmentación.
• Definir la estrategia de descarte: fstrim en línea frente a fstrim periódico, propagándolo por todas las capas.
• Copias de seguridad y recuperación: Probar los procesos fsfreeze y Snapshot, verificar de forma realista el tiempo de inactividad.
• Mediciones A/B: Modificar solo una variable y correlacionar los resultados con las métricas de la aplicación.

Resumen: Una guía para la toma de decisiones sin mitos

XFS y EXT4 ofrecen un rendimiento muy alto en NVMe; las diferencias suelen ser mínimas moderado y dependen en gran medida del perfil de E/S. Las cargas aleatorias con bloques pequeños se sitúan muy próximas entre sí, mientras que los flujos secuenciales largos suelen dar ventaja a XFS. EXT4 destaca por un rendimiento ligeramente superior en algunos patrones transaccionales, mientras que XFS ofrece latencias constantes en pruebas de duración prolongada. La versión del núcleo, los modelos NVMe, el programador, la profundidad de E/S, el espacio libre y las opciones de montaje suelen influir en el resultado más que la mera elección del sistema de archivos. Quien realice mediciones precisas y comprenda sus propias cargas de trabajo tomará una decisión fundamentada, sin leyendas y con datos medibles Beneficios.