Las escrituras grandes en EXT4 acaban de dejar de recorrer el mismo camino que en 2006. El sistema de ficheros más extendido en servidores Linux estrena una ruta de entrada y salida con buffer dentro de las novedades de EXT4 Linux 7.4: abandona el manejo clásico de bloques y se apoya en IOmap, el marco que ya usan XFS y otros sistemas de ficheros modernos para traducir posiciones de un fichero a bloques del disco. El cambio entró en el árbol principal la noche del domingo 25 al lunes 26 de octubre, cuando Linus Torvalds aceptó el pull que Theodore Ts’o había enviado el jueves 22 y por el que tuvo que preguntar el domingo.
Detrás de la novedad hay 31 parches firmados por Zhang Yi, ingeniero de Huawei que lleva más de dos años empujando esta conversión. Las pruebas que acompañan a la serie, medidas con FIO sobre una máquina virtual de cuatro núcleos y un dispositivo de bloque respaldado por memoria, muestran un salto del 105% en escrituras de 1 MiB que evitan la caché y del 30% en escrituras de 64 KiB con writeback de fondo. Son cifras del propio autor, no de un banco de pruebas independiente, y conviene leerlas con esa cautela.
La letra pequeña explica por qué la noticia no ha llegado a tu escritorio. La ruta nueva no se activa sola: exige la opción de montaje `buffered_iomap`, convive mal con media docena de funciones clásicas de EXT4 y se retira sola cuando encuentra una de ellas. Quien administra un NAS o un servidor de copias tiene motivos para probarla este trimestre; quien solo abre el navegador y guarda documentos apenas notará la diferencia, porque ahí el cuello de botella casi nunca está en el sistema de ficheros.
De buffer heads a IOmap, treinta y un parches después
EXT4 nació heredando la fontanería de EXT3, que describe el estado de cada bloque en memoria con estructuras llamadas buffer heads. Cada una arrastra su propia contabilidad y su propio candado, de modo que escribir un fichero de varios gigabytes implica administrar cientos de miles de objetos pequeños.
El marco IOmap cambia el enfoque: describe rangos de bloques y trabaja con folios, las páginas de memoria que el kernel maneja desde hace años en lugar de páginas sueltas de 4 KiB.
Zhang Yi no convirtió solo la escritura. La serie reescribe también la lectura con buffer, el writeback, el camino de mmap y el troceado de rangos en bloques parciales, además de reordenar el zerado del último bloque de un fichero que crece. Ese detalle es el que más quebraderos de cabeza deja, porque toca la actualización de `i_disksize`, el tamaño que EXT4 anota en el inodo antes de que el fichero esté realmente en el disco. Ts’o describió el resultado como mejoras «significativas» en escrituras grandes y añadió arreglos sueltos para fast commit y para evitar bloqueos y lecturas fuera de límites cuando el sistema de ficheros llega corrupto.
La fusión obligó a esperar. Torvalds había cerrado ya las ramas de arquitecturas y controladores y volvió a los sistemas de ficheros el domingo por la noche, con un comentario socarrón sobre lo lento que iba todo por culpa de dos días de buceo. El hilo del pull deja el merge sellado a las 02:20 UTC del lunes 26.
¿Qué midió el autor con FIO?
Las cifras del anuncio salen de una batería con tamaños de bloque de 1 KiB a 1 MiB, con y sin fsync, con y sin reescritura de bloques existentes y con la marca de escritura sin caché que el kernel expone a las aplicaciones. Los números están en MiB por segundo y comparan el camino clásico con el de IOmap:
| Escenario de escritura |
EXT4 con buffer heads (MiB/s) |
EXT4 con IOmap (MiB/s) |
Diferencia |
| 1 MiB, solo caché de página |
4.295 |
5.780 |
+35% |
| 64 KiB, con writeback de fondo |
734 |
957 |
+30% |
| 64 KiB, sin caché |
415 |
698 |
+68% |
| 1 MiB, sin caché |
1.404 |
2.883 |
+105% |
| 1 KiB con fsync tras cada escritura |
0,71 |
0,60 |
-15% |
La tabla cuenta una historia incómoda para el marketing fácil. Donde el bloque es grande y el dato viaja en tromba, la ruta nueva casi duplica el rendimiento. Donde el patrón es una escritura diminuta seguida de fsync, el resultado empeora entre un 7% y un 15%, y en lectura la diferencia no es significativa. La serie completa documenta esos retrocesos en vez de esconderlos, algo poco habitual en un parche que llega a mainline.
Aquí es donde la noticia se vuelve útil para decidir. Un servidor de respaldos que reescribe ficheros de imágenes de máquina virtual, un NAS que recibe copias por rsync o un almacén de registros comprimidos trabajan justo en la franja que mejora. Una base de datos pequeña con transacciones frecuentes, no.
Las funciones que quedan aparcadas
La ruta nueva no cubre todavía todo lo que EXT4 sabe hacer, y ese hueco es la razón de que el interruptor esté apagado por defecto. Si el sistema de ficheros necesita alguna de estas piezas, el kernel devuelve el inodo al camino antiguo sin pedir permiso:
- Desfragmentación en línea, la que reordena un fichero mientras sigue abierto.
- Datos inline, el truco que mete contenidos diminutos dentro del propio inodo.
- Verificación de integridad con fs-verity y cifrado por fichero con fscrypt.
- Inodos sin extents, herencia de los volúmenes creados con EXT3.
- Modo `data=journal`, que algunos servidores usan para bases de datos.
Un volumen recién formateado con los valores por defecto sí entra. Un volumen antiguo, cifrado con fscrypt o convertido desde EXT3, se queda fuera hasta que el trabajo avance, porque cada una de esas funciones obliga a tocar caminos de bloqueo que el parche todavía no cubre.
El precio de apagar data=ordered
Hay una segunda renuncia, menos visible en el manual y más relevante para quien cuida datos. La ruta de IOmap no usa el modo `data=ordered`, el mecanismo que garantiza que los datos llegan al disco antes que los metadatos que los describen.
En su lugar, EXT4 reserva extents sin escribir para las ampliaciones y pospone la actualización de `i_disksize` hasta que el bloque zerado del final está realmente en el disco. El propio Zhang Yi admite el compromiso en la carta de presentación: tras un corte de corriente, el tamaño del inodo puede quedar actualizado mientras el contenido de esa cola se lee como ceros.
Conviene matizar que la garantía rota es estrecha y que el autor la considera aceptable. Aun así, quien elige `data=ordered` por su comportamiento ante caídas debería pensarlo dos veces antes de cambiarlo por velocidad secuencial. La opción contraria existe, se llama `nobuffered_iomap` y cierra el interruptor sin desmontar nada más.
Dónde se nota la mejora (y dónde no)
El resto de la ventana de 7.4 acumulaba 6.753 cambios sin merges el viernes 23, según el balance de la merge window, y esta pieza de EXT4 es de las que no aparecen en la portada de ninguna distribución. Nadie va a notar el cambio al arrancar el escritorio. Lo notará quien copie un respaldo de 400 GB y mire el reloj, o quien mueva imágenes de disco entre dos volúmenes EXT4 de la misma máquina.
Tampoco es la única novedad del ciclo. Linux 7.3, publicado el domingo 18, ya había movido piezas en el planificador y en la memoria de las GPU AMD, según el resumen de aquellas semanas. Con 7.4 aún en ventana, lo que llega son cimientos.
Un interruptor que espera su turno
Con el código ya en mainline, la pregunta pasa a ser cuándo deja de ser opcional. Ts’o fue explícito en que la ruta se queda detrás de una opción de montaje justamente porque faltan funciones, y la serie deja abiertas notas sobre lo que queda por hacer: desfragmentación en línea, datos inline y compatibilidad con los volúmenes antiguos. La primera candidata de 7.4 no llegará antes del 1 de noviembre, así que ninguna distribución estable lo verá este mes.
Mientras tanto, el consejo práctico cabe en una línea de `/etc/fstab` y una prueba: monta un volumen de laboratorio con `buffered_iomap`, copia encima un fichero grande, compara tiempos y revisa si ese volumen usa cifrado o `data=journal`. Si algo de eso aparece, la ruta nueva no se activará y no habrás perdido nada. Si el volumen está limpio, ganarás el rendimiento que casi nadie mide y que casi todos agradecen cuando el reloj del respaldo se acerca a la madrugada.
