Linux 7.2: +5% de IOPS en EXT4 y XFS con dos líneas
El kernel Linux 7.2 mejora un 5% el IOPS en EXT4 y XFS gracias a un cambio mínimo: saltear un memset innecesario en la función iomap_iter(). El ajuste lo mandó Fengnan Chang, ingeniero de Bytedance, y según Phoronix (15 de junio de 2026) el beneficio aparece en escenarios de alto IOPS con NVMe e io_uring.
La optimización Linux 7.2 IOPS es un parche en la capa IOmap del kernel que elimina una escritura de memoria desperdiciada al final de cada iteración de I/O. IOmap es el framework de VFS que traduce los offsets de datos de un archivo a su ubicación física en el disco. Afecta a EXT4 y XFS y rinde mejor con almacenamiento NVMe y polling vía io_uring.
En 30 segundos
- +5% de IOPS en EXT4 y XFS con cargas 4k randread sobre NVMe usando io_uring.
- El cambio son dos líneas: se saltea el
memsetdel iterador IOmap cuando ya terminó la iteración. - Autor: Fengnan Chang, ingeniero de Bytedance, que detectó el ancho de banda de escritura tirado a la basura.
- Bonus: el mismo pull request agrega la infraestructura VFS para soportar FS-VERITY en XFS con un árbol Merkle post-EOF.
- Requisito real: NVMe + io_uring. En HDD o SATA el efecto es casi imperceptible.
¿Qué es IOmap y para qué lo usan EXT4 y XFS?
Ponele que tu aplicación pide leer un bloque de 4k de un archivo. El kernel no tiene ni idea de dónde está ese bloque en el disco físico: tiene un offset lógico dentro del archivo y nada más. Ahí entra IOmap.
IOmap es el framework de VFS que mapea los offsets de datos de un archivo en memoria a sus ubicaciones físicas en el almacenamiento. Tanto EXT4 como XFS lo usan para resolver ese puente entre “lo que pide el programa” y “dónde están los bytes de verdad”. Cualquiera que haya peleado con I/O de bajo nivel sabe que esa traducción se ejecuta millones de veces por segundo en un servidor cargado. Por eso un detalle chico, repetido tantas veces, se vuelve plata.
¿Cómo logra Linux 7.2 +5% de IOPS moviendo dos líneas?
Acá viene lo bueno. La función iomap_iter() hacía un memset de la estructura del iterador en cada vuelta. El problema: cuando la iteración ya terminó, el caller descarta el iterador. O sea, escribías ceros en memoria que nadie iba a volver a leer. Relacionado: en pipelines CI/CD de alta carga.
El texto del commit lo dice sin vueltas: “Skip the memset of the iomap in iomap_iter() once the iteration is done. In high-IOPS scenarios (4k randread NVMe polling via io_uring) the pointless memset wasted memory write bandwidth; this improves IOPS by about 5% on ext4 and xfs.”
Traducido: ese memset “inútil” gastaba ancho de banda de escritura de memoria para nada. Fengnan Chang, de Bytedance, lo notó, corrió el memset de lugar y listo. ¿Cinco por ciento por mover dos líneas? Sí, en serio. No es magia, es sacar trabajo que sobraba en el camino caliente del I/O.
¿Por qué la mejora solo se nota con NVMe e io_uring?
El beneficio aparece cuando el cuello de botella deja de ser el disco y pasa a ser la CPU y la memoria. Con un SSD NVMe haciendo 4k randread y polling vía io_uring, el dispositivo responde tan rápido que cada ciclo de memoria desperdiciado se siente.
En un HDD o un SATA viejo, el disco tarda tanto en responder que ese memset de más queda escondido detrás de la latencia mecánica. Es como optimizar la salida de boxes cuando el auto anda a 40 por hora: no cambia nada. El polling de io_uring saca al kernel del esquema clásico de interrupciones, y en ese régimen de alto IOPS cada instrucción de menos cuenta. Esto se conecta con lo que analizamos en cuando ejecutás Jenkins en Linux.
EXT4 vs XFS: ¿cuál se beneficia más?
Los dos suben parejo, alrededor del 5%, porque comparten la misma capa IOmap. La diferencia está en dónde los vas a encontrar trabajando.
| Aspecto | EXT4 | XFS |
|---|---|---|
| Mejora de IOPS en 7.2 | ~5% (4k randread NVMe) | ~5% (4k randread NVMe) |
| Uso típico | Propósito general, root de la mayoría de distros | Almacenamiento de alto volumen, paralelismo |
| Escenario fuerte | VPS y servidores estándar | Bases grandes, almacenamiento distribuido (Ceph) |
| FS-VERITY en 7.2 | Ya soportado de antes | Nueva infraestructura (árbol Merkle post-EOF) |
Si corrés cargas con mucho paralelismo y archivos grandes, XFS suele ser tu elección. Para un servidor común, EXT4 zafa perfecto. La optimización no te obliga a migrar de uno a otro: los dos ganan lo mismo.
¿Necesitás actualizar a Linux 7.2 para aprovecharlo?
Sí, porque es un cambio a nivel kernel. No hay flag de montaje ni opción de configuración: viene en el código de IOmap de la 7.2 y se activa solo en cuanto booteás ese kernel. No tocás nada en tus filesystems existentes y son 100% compatibles.
De yapa, el mismo pull request suma la infraestructura VFS para FS-VERITY en XFS con un árbol Merkle ubicado después del fin de archivo (post-EOF). FS-VERITY te deja verificar la integridad de archivos de solo lectura, algo útil para binarios y paquetes que no querés que nadie altere. Si gestionás la infraestructura web donde corre todo esto, podés montar tus VPS con Linux 7.2 o superior en donweb.com y tener el beneficio sin configurar nada raro.
¿Cómo validás que estás aprovechando la optimización?
Primero confirmá la versión del kernel con uname -r. Después medí. La herramienta estándar para esto es fio: armás un test de 4k randread con ioengine=io_uring y comparás IOPS antes y después de bootear la 7.2. Podés consultar nuestro artículo sobre distribuir contenido técnico globalmente.
Para que la prueba tenga sentido necesitás que se cumpla la combinación completa: ejecutás el benchmark sobre un dispositivo NVMe, con io_uring activo y polling habilitado, medís el promedio de varias corridas, descartás la primera por el warm-up del cache y recién ahí comparás los números, porque si cambiás una sola variable del entorno el 5% se te diluye en el ruido. Si ves io_uring marcado como engine en la salida de fio, vas por buen camino.
Errores comunes al medir esta mejora
- Probar sobre HDD o SATA y no ver nada. Es esperable. El parche apunta a alto IOPS sobre NVMe. En discos lentos el efecto queda tapado por la latencia del medio.
- Usar el ioengine equivocado en fio. Si corrés con
libaioo I/O síncrono en vez deio_uring, no estás midiendo el camino que el parche optimiza. - Comparar contra otra versión de kernel con parches mezclados. Cambiá solo el kernel. Si tocás scheduler, drivers o config al mismo tiempo, no sabés a qué atribuir la diferencia.
- Esperar 5% en cargas secuenciales grandes. El número sale de 4k randread. En lecturas secuenciales de archivos grandes el patrón es otro y el ahorro casi no aparece.
Preguntas Frecuentes
¿Qué optimización trae Linux 7.2 para EXT4 y XFS?
Linux 7.2 saltea un memset innecesario en la función iomap_iter() una vez terminada la iteración, lo que mejora el IOPS cerca de un 5% en EXT4 y XFS. El cambio viene de Fengnan Chang, ingeniero de Bytedance.
¿Necesito io_uring para aprovechar la mejora?
Sí, en la práctica el beneficio aparece en escenarios de alto IOPS con NVMe usando polling vía io_uring. Sin ese patrón de acceso, el ahorro de ancho de banda de memoria queda tapado por la latencia del almacenamiento.
¿Qué es el memset en IOmap y por qué importa optimizarlo?
El memset escribía ceros en la estructura del iterador IOmap en cada vuelta. Como el caller descartaba ese iterador al terminar, era trabajo desperdiciado que gastaba ancho de banda de escritura de memoria. Eliminarlo libera ese ancho de banda para I/O real. Cubrimos ese tema en detalle en ejecutar agentes sin conexión.
¿Esta mejora rompe la compatibilidad con mis filesystems?
No. Es una optimización interna del kernel que no cambia el formato en disco de EXT4 ni XFS. Tus filesystems existentes siguen funcionando igual y solo necesitás bootear el kernel 7.2 para activarla.
¿Qué otra cosa trae el mismo pull request de VFS?
Agrega la infraestructura VFS para implementar FS-VERITY en XFS con un árbol Merkle post-EOF. FS-VERITY permite verificar la integridad de archivos de solo lectura, útil para proteger binarios y paquetes contra modificaciones.
Conclusión
La optimización Linux 7.2 IOPS demuestra algo que cualquiera que toca kernel sabe: en el camino caliente del I/O, sacar trabajo que sobra rinde más que agregar features. Cinco por ciento gratis en EXT4 y XFS, sin migrar nada, solo por bootear un kernel nuevo.
¿Qué hacés con esto? Si corrés cargas de base de datos o almacenamiento intensivo sobre NVMe con io_uring, poné la 7.2 en tu roadmap de actualización y medí con fio antes y después. Si tu workload es secuencial o vive en discos lentos, no esperes milagros, pero tampoco perdés nada. Y si estás armando infraestructura nueva, arrancá directo con un kernel reciente para no dejar ese 5% en la mesa.
