Cambios Linux 7.2 almacenamiento: NVMe, RAID y más
Linux 7.2 sumó una tanda fuerte de cambios en almacenamiento que se fusionaron (merged) a mediados de junio de 2026, según el reporte de Phoronix del 17 de junio. Entre los cambios en almacenamiento de Linux 7.2 más relevantes están la reescritura de task_work en IO_uring, el cifrado inline dm-inlinecrypt en Device Mapper, mejoras NVMe con P2P DMA y timeouts por controlador, y correcciones de deadlock en RAID1 y RAID10.
En 30 segundos
- IO_uring: reescritura de la infraestructura task_work, notificaciones de zero-copy receive (zcrx) vía un CQE dedicado, y mejoras de fiabilidad para ZCRX.
- NVMe: atributos sysfs de timeout admin/IO por controlador, P2P DMA para dispositivos multipath, y un grupo nuevo de sysfs con contadores por controlador.
- Device Mapper: llega dm-inlinecrypt, un target de cifrado inline alternativo a dm-crypt.
- RAID (MD): se arregla un deadlock en la ruta de recuperación de errores de lectura en RAID1 y RAID10.
- Bloques: el subsistema ahora soporta el análisis de contexto de locks de Clang (LLVM).
¿Cómo baja el uso de CPU el receive cero-copia (zcrx) en Linux 7.2?
Pensá en un servidor que recibe tráfico de red a alta velocidad. En el camino tradicional, el kernel copia los datos de su propio buffer al espacio de memoria del proceso de usuario. Esa copia cuesta ciclos de CPU, y a 10, 40 o 100 Gbps se nota.
El zero-copy receive (zcrx) evita esa copia: los datos van directo a la memoria del usuario sin el rebote intermedio kernel-a-usuario. No es nuevo del todo, pero en Linux 7.2 el equipo de IO_uring metió mano para que sea más usable. Hay notificaciones de usuario para zcrx que comunican de vuelta al espacio de usuario mediante un CQE (completion queue entry) dedicado, y mejoras de fiabilidad para ZCRX.
El otro cambio grande acá es la reescritura de la infraestructura task_work para mejor rendimiento. ¿Por qué importa? Porque task_work es el mecanismo que IO_uring usa para diferir trabajo y ejecutarlo en el contexto correcto. Si esa pieza es más eficiente, todo lo asíncrono que pasa por encima respira mejor. Phoronix no da un porcentaje concreto de mejora, así que tomalo como una optimización de base, no como un número de marketing. Cubrimos ese tema en detalle en pipelines de CI/CD en 2026.
NVMe en Linux 7.2: timeouts por controlador, P2P DMA y contadores
El código NVMe se llevó varias cosas útiles para quien administra storage en serio.
- Timeouts por controlador: se agregaron atributos sysfs de timeout admin e I/O por cada controlador. Antes el timeout era más global; ahora podés afinarlo por dispositivo, lo que ayuda cuando tenés controladores con comportamientos distintos en el mismo host.
- P2P DMA en multipath: se habilitó PCI peer-to-peer DMA (P2PDMA) para dispositivos multi-path. P2PDMA es cuando dos dispositivos PCIe (por ejemplo, un SSD NVMe y una placa de red) se transfieren datos directo entre ellos, sin pasar por la RAM del sistema ni meter a la CPU en el medio.
- Contadores por controlador: hay un grupo de atributos sysfs nuevo que expone contadores por controlador. Más visibilidad para monitoreo y diagnóstico.
El de P2PDMA es el que más cambia el juego en cargas pesadas: sacar a la CPU del camino de datos libera ciclos para lo que de verdad importa.
¿Qué es dm-inlinecrypt y en qué se diferencia de dm-crypt?
Device Mapper (DM) es el framework del kernel Linux para mapear dispositivos de bloque virtuales sobre dispositivos físicos. Sobre DM viven cosas que ya usás: LVM, RAID por software, y el cifrado de disco con dm-crypt.
La novedad más comentada del lado de DM en Linux 7.2 es la introducción de dm-inlinecrypt, un target de cifrado en línea. La diferencia con dm-crypt es dónde y cómo se hace el cifrado. dm-crypt cifra por software en la CPU. dm-inlinecrypt usa motores de cifrado inline (inline encryption hardware), donde el cifrado ocurre en el camino del I/O sin cargar al procesador. Más contexto en automatización de builds modernos.
| Aspecto | dm-crypt | dm-inlinecrypt |
|---|---|---|
| Dónde cifra | Por software, en la CPU | Inline, en el camino del I/O |
| Uso de CPU | Más alto bajo carga | Menor si hay hardware de cifrado inline |
| Madurez | Años en producción, muy probado | Recién llega en Linux 7.2 |
| Cuándo usarlo | Caso general, máxima compatibilidad | Storage de alto throughput con soporte inline |
¿Significa que dm-crypt quedó viejo? No. dm-crypt sigue siendo la opción por defecto y la más probada. dm-inlinecrypt es para escenarios específicos donde el cifrado por CPU es el cuello de botella.
Correcciones de deadlock en RAID1 y RAID10
Un deadlock es cuando dos partes del sistema se quedan esperando una a la otra y ninguna avanza. Todo se traba. En el subsistema MD (el RAID por software de Linux) había un deadlock en la ruta de recuperación de errores de lectura que afectaba a RAID1 y RAID10.
Ponele que un disco del array devuelve un error de lectura. El kernel arranca la recuperación, y bajo ciertas condiciones esa ruta se trababa. En Linux 7.2 se corrigió ese deadlock. Si corrés arrays RAID1 o RAID10 por software, este fix solo ya justifica mirar la versión.
El código MD también maneja mejor la propagación de PCI P2PDMA desde los dispositivos miembro hacia el dispositivo RAID. Es la misma capacidad de transferencia directa entre dispositivos PCIe que vimos en NVMe, ahora respetada a nivel del array. Para más detalles técnicos, mirá documentación internacional del kernel.
Buffers registrados y filtrado de opcodes en IO_uring
Los registered buffers de IO_uring son buffers que la aplicación registra una vez con el kernel para evitar el costo de mapearlos en cada operación. Linux 7.2 trae mejoras en esos buffers registrados, lo que reduce overhead en aplicaciones con muchas operaciones I/O asíncronas.
Otro detalle: ahora hay soporte para filtrado de opcodes en IORING_OP_CONNECT, más varias limpiezas de código. Es menos vistoso que dm-inlinecrypt, pero suma para quien escribe software sobre IO_uring.
Análisis de locks de Clang en el subsistema de bloques
El subsistema de bloques completo ahora soporta el análisis de contexto de locks de Clang (LLVM). ¿Qué gana el usuario final? Indirectamente, estabilidad. Ese análisis ayuda al compilador a detectar problemas de concurrencia (locks mal tomados o mal liberados) en tiempo de compilación, antes de que se conviertan en bugs raros en producción.
No vas a “notar” esta función. Es de las cosas que importan justamente cuando no pasan: menos race conditions en la capa que mueve todos tus datos. Lo explicamos a fondo en agentes locales sin dependencias externas.
¿Conviene actualizar? Casos de almacenamiento en Linux 7.2
No todos necesitan correr a actualizar. Pero hay perfiles claros que se benefician:
- Quien corre RAID1/RAID10 por software: el fix de deadlock en recuperación de errores de lectura es razón suficiente.
- Cargas de red de alto throughput: las mejoras de zcrx y task_work en IO_uring apuntan justo ahí.
- Storage NVMe en producción: timeouts por controlador y contadores por sysfs dan más control y observabilidad.
- Entornos que evalúan cifrado inline: dm-inlinecrypt abre una puerta que antes no estaba.
Si administrás VPS o servidores propios y querés probar estos cambios sin tocar tu infra crítica, levantar un entorno de pruebas en infraestructura como la de donweb.com es una forma barata de medir antes de migrar producción. Eso sí: 7.2 todavía está en proceso de merge, no es para poner en un servidor de producción hoy.
Errores comunes al evaluar estos cambios
- Creer que dm-inlinecrypt reemplaza a dm-crypt: no lo hace. dm-crypt sigue siendo el default probado. dm-inlinecrypt es para casos con hardware de cifrado inline donde la CPU es el cuello de botella.
- Esperar mejoras de rendimiento garantizadas en zcrx: el beneficio depende mucho de tu carga de red y de cómo esté escrita la aplicación. No hay un porcentaje oficial publicado para 7.2.
- Actualizar producción apenas se mergea el código: que algo esté merged en la ventana de 7.2 no significa que el kernel esté liberado y estable. Probalo en un entorno aparte primero.
- Activar P2PDMA sin verificar el hardware: el peer-to-peer DMA depende de la topología PCIe. No todos los setups lo soportan ni se benefician igual.
Preguntas Frecuentes
¿Cuáles son los cambios principales de almacenamiento en Linux 7.2?
Los cambios clave son la reescritura de task_work y las mejoras de zero-copy receive en IO_uring, P2P DMA y timeouts por controlador en NVMe, el target de cifrado dm-inlinecrypt en Device Mapper, y correcciones de deadlock en RAID1 y RAID10. Se fusionaron en la ventana de junio de 2026.
¿Qué es dm-inlinecrypt?
dm-inlinecrypt es un target nuevo de Device Mapper introducido en Linux 7.2 que hace cifrado en línea de dispositivos de bloque. A diferencia de dm-crypt, que cifra por software en la CPU, dm-inlinecrypt usa motores de cifrado inline para no cargar al procesador.
¿Cómo funciona el zero-copy receive (zcrx) en Linux?
El zero-copy receive entrega los datos de red directo a la memoria del proceso de usuario, sin la copia intermedia del buffer del kernel al espacio de usuario. En Linux 7.2, IO_uring suma notificaciones vía un CQE dedicado y mejoras de fiabilidad para ZCRX.
¿Qué ventaja tiene P2P DMA en NVMe?
El PCI peer-to-peer DMA permite que dos dispositivos PCIe se transfieran datos directo entre ellos sin pasar por la RAM del sistema ni involucrar a la CPU. En Linux 7.2 se habilitó para dispositivos NVMe multi-path, lo que libera ciclos de CPU en cargas de almacenamiento intensivo.
¿Cuándo se libera Linux 7.2?
Al 17 de junio de 2026, Linux 7.2 está en su ventana de merge, con el código de almacenamiento integrándose progresivamente. La fecha exacta de release estable no estaba confirmada en las fuentes; conviene seguir el ciclo de desarrollo del kernel para el dato oficial.
Conclusión
Linux 7.2 no trae un titular único que vuele cabezas, trae una suma de mejoras de almacenamiento bien repartidas: IO_uring más eficiente, NVMe con más control y P2P DMA, cifrado inline opcional vía dm-inlinecrypt, y un fix de deadlock en RAID1/RAID10 que va a agradecer cualquiera que dependa de RAID por software. ¿Qué hacer ahora? Si administrás storage en serio, montá un entorno de pruebas, medí con tu carga real, y prestá atención especial al fix de RAID y a las funciones NVMe. No migres producción hasta que el kernel esté liberado y estable.
