# Linux 7.4-rc2 llega con FAT32 hasta 162 veces más rápido > Torvalds publica la segunda candidata del kernel con un parche de preasignación en FAT32, arreglos de memoria reportados por Anthropic y una señal en BPF. > Por José Maldonado · Tecnología · 2026-11-10 Linus Torvalds publicó la noche del domingo 8 de noviembre la segunda candidata de Linux 7.4, ocho días después de un rc1 que calificó como el mayor de la historia del proyecto: casi 20.000 commits frente a los 15.000 habituales. La versión estable se espera para finales de diciembre y suena como candidata a convertirse en el próximo kernel de soporte a largo plazo. La lista de cambios reales es más modesta de lo que sugiere el tamaño. Buena parte del volumen son conversiones automáticas de Coccinelle que Torvalds recibió durante la ventana de fusión y retuvo mientras estaba de viaje, y otro tanto son volcados de registros de la GPU de AMD. Al quitar ese ruido, el kernel se reparte en tres tercios. [El reparto es de un tercio por lado](https://www.linuxcompatible.org/story/linux-kernel-74rc2-released-largest-merge-window-in-history-meets-stabilization-test/): drivers (GPU, red y sonido), red y BPF, y el resto, donde entran sistemas de archivos, gestión de memoria y cambios de arquitectura. [En BPF los arreglos llegan más rápido que los informes nuevos](https://www.webpronews.com/linux-7-4-rc2-torvalds-bpf-ai-bug-reports/), que es la parte del anuncio que más está circulando. Ese dato, que parece menor, es la primera señal de que la marea de parches generada por la detección automática de fallos empieza a tener respuesta del otro lado. ## FAT32 se lleva la mejora más visible El cambio con más impacto cotidiano es una preasignación de espacio en FAT32. El desarrollador Matheus Alves de Almeida movió el trabajo a un ayudante llamado \`fat\_preallocate()\` y usó una ruta específica para no volver a comprobar el tamaño del archivo en cada escritura. En montajes síncronos con clústeres pequeños, las mediciones publicadas llegan a mejoras de hasta 162 veces. Un segundo ajuste de FAT, fusionado antes en el ciclo, llegó a 265 veces en el mismo tipo de prueba. Son cifras que solo aparecen en escenarios concretos, y conviene leerlas así: no hablan de un escritorio normal con ext4, sino de tarjetas y dispositivos con FAT donde cada escritura síncrona se pagaba a precio de oro. Para quien prepara imágenes para Raspberry Pi, cámaras o equipos con arranque desde FAT, la diferencia se nota en el tiempo de copia. Para el resto, es un recordatorio de que el sistema de archivos más antiguo del ecosistema sigue recibiendo atención décadas después. Conviene no confundir la mejora con una transformación. FAT32 sigue sin permisos POSIX, sin enlaces simbólicos y sin registro de transacciones, así que la ganancia no lo convierte en candidato para un servidor de archivos ni para un portátil con ext4 o btrfs. Lo que cambia es el coste de una operación concreta, no la naturaleza del sistema. El ciclo anterior ya había movido [FAT32 con mejoras de hasta 4,06 veces](https://observatorioblockchain.com/tecnologia/linux-7-5-fat32-4-06x-airdrop-t2/), y el [cambio de ext4 en 7.4](https://observatorioblockchain.com/tecnologia/ext4-iomap-linux-7-4-escrituras/) comparte filosofía: quitar trabajo del camino caliente. ## Memoria, BPF y el rastro de la IA El lote de gestión de memoria llegó por una vía nueva. David Hildenbrand, ingeniero de Arm, empezó a enrutar parte de los parches por un árbol propio de Core MM en lugar de depender solo de Andrew Morton, y en esa tanda entraron fallos que llevaban años escondidos. El alcance es amplio: páginas enormes transparentes, GUP, KSM, USERFAULTFD, shmem y memfd, y hugetlb. Los arreglos cubren fugas de información, escrituras fuera de límites, pérdida y corrupción de datos, uso después de liberar, bloqueos y bucles que no se pueden matar. Hildenbrand fue explícito sobre el origen: la mayoría de los problemas los reportó Anthropic. Ese detalle conecta con el otro titular del ciclo. En BPF, Alexei Starovoitov firmó 40 parches de endurecimiento del verificador y de las arenas de ejecución, y contó que en su subsistema los arreglos ya salen más rápido que los informes nuevos. Torvalds lo recogió con su tono habitual: si es verdad, es una buena señal, y añadió que no conviene aguantar la respiración. El resto del rc2 incluye protección de concurrencia en Bluetooth, rechazo de marcas IPsec mal formadas en xfrm, correcciones de uso después de liberar en NVMe, trabajo en la MMU de invitado de KVM y una barrida de 22 parches en hwmon, entre otros cientos de cambios menores. ## Qué significa para quien no compila kernels Para la mayoría, nada inmediato. Un release candidate es una instantánea de pruebas y solo debería recibir correcciones, no funciones nuevas; instalarlo en producción es una decisión de laboratorio. La recomendación sigue siendo quedarse en el kernel estable de la distribución. Lo que sí cambia es el calendario de fondo. Si el ritmo se mantiene, 7.4 podría publicarse el 20 de diciembre con siete candidatas, o el 27 con ocho. Greg Kroah-Hartman lo adoptaría como LTS a principios de 2027, con años de parches retroportados detrás. Ese horizonte explica por qué tanta gente está mirando este ciclo. Quien tenga hardware AMD nuevo, discos con FAT o cargas de trabajo con contenedores tiene motivos concretos para esperar a la estable en lugar de perseguir cada candidata. ## La marea de parches y su factura Desde que Anthropic lanzó su modelo de búsqueda de fallos en abril, el volumen de errores encontrados en software maduro creció hasta límites que los equipos no habían visto. Microsoft corrigió 974 fallos en septiembre, después de 622 en julio y 206 en junio; Oracle llegó a 1.449 en un solo mes. El kernel, con más de 40 millones de líneas, absorbe esa marea con mantenedores voluntarios y una ventana de fusión que ya se acerca a las 20.000 entregas. La pregunta que subyace en el rc2 es si el proceso aguanta o si el cuello de botella se traslada de encontrar fallos a revisar los parches que los arreglan. La respuesta de Torvalds es pragmática: prefiere que el trabajo generado por IA llegue durante la ventana de fusión, cuando hay margen para revisarlo, y no como una avalancha de correcciones de emergencia en las semanas de estabilización. ## Lo que queda por comprobar La señal de BPF es un dato de un subsistema, no una tendencia general, y el propio Torvalds la matizó en el anuncio. El resto del kernel sigue recibiendo más informes de los que puede cerrar, y el calendario de siete u ocho candidatas depende de que no aparezca una regresión seria. Para quien quiera probar, la fuente está en el árbol de Torvalds y el tarball en kernel.org; para quien solo quiera un equipo que arranque, la respuesta sigue siendo la misma que hace un mes: esperar a la estable de diciembre y, si se adopta como LTS, actualizar entonces con la tranquilidad de tener años de mantenimiento por delante.