Las novedades de Linux 4.5

Ya se ha anunciado la versión 4.5 de Linux. Esta versión añade una nueva llamada al sistema, copy_file_range(2), que permite copiar archivos sin el coste de transferir los datos a través del espacio de usuario; soporte experimental de la gestión de energía Powerplay en GPUs Radeon modernas; mejoras de escalabilidad en la gestión del espacio libre de Btrfs; soporte para el Undefined Behavior Sanitizer de GCC (-fsanitize=undefined); soporte para Forwarded Error Correction en el objetivo verity del device-mapper, soporte para la bandera MADV_FREE en madvise(); la nueva jerarquía unificada de cgroup ya se considera estable; mejoras de escalabilidad en sockets UDP que hacen uso de SO_REUSEPORT; y mejoras de escalabilidad para epoll. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.


· Copias más rápidas con la llamada al sistema copy_file_range(2)

Copiar un archivo consiste en leer datos de un archivo a la memoria de un proceso, y luego copiar los datos de esa memoria al archivo destino. No hay nada malo con esta manera de hacer las cosas, pero requiere hacer copias extra de los datos al copiarlos a/desde la memoria del proceso. En esta versión Linux añade una nueva llamada al sistema, copy_file_range(2), que permite copiar un rango de datos de un archivo a otro, evitando el coste mencionado de transferir los datos del kernel al proceso y luego de nuevo al kernel.

Esta llamada al sistema sólo es ligeramente más rápida que cp, porque el coste de hacer las copias apenas es nada, comparado con el tiempo que toma hacer la E/S, pero hay algunos casos en los que puede ayudar mucho. En sistemas de archivos de red, como NFS, copiar los datos implica enviar los datos del servidor al cliente a través de la red, y luego enviarlos de nuevo del cliente al nuevo archivo en el servidor. Pero con copy_file_range(2), el cliente puede ordenar al servidor NFS que copie un rango de datos específico de un archivo a otro, sin transferir los datos a través de la red (para NFS, esto requiere también el soporte de la característica "copia del lado del servidor, presente en el próximo NFSv4.2, y también soportado experimentalmente en esta versión). En próximas versiones, los sistemas de archivos locales como Btrfs, o algunos dispositivos de almacenamiento especializados, podrían usar esta llamada al sistema para optimizar la copia de datos, o se podrían eliminar algunas de las limitaciones actuales (la copia de datos está limitada a archivos que se encuentren en la misma montura y superbloque, y que las copias no sean entre partes del mismo archivo)

· Gestión de energía PowerPlay experimental en el driver amdgpu

Las GPUs modernas arrancan en modo de bajo consumo y rendimiento, y necesitan alterar dinámicamente su frecuencia para funcionar en los modos que proporcionan el mejor rendimiento. Pero eso no puede hacerse sin gestión de energía. Esta versión incorpora soporte de Powerplay en el driver amdgpu para GPUs Tonga y Fiji, y APUs integradas Carrizo y Stoney.

Powerplay es el nombre dado por AMD al sistema de gestión de energía presente en varias de sus GPUs y APUs y soportado en el driver propietario Catalyst, y ahora aspira a reemplazar la actual gestión de energía del driver amdgpu. En las GPUs soportadas el rendimiento será mucho más alto.

Powerplay no está activado por defecto en todos los tipos de hardware soportado debido a su carácter experimental, en esos casos puede intentar forzarse su uso con la opción del kernel "amdgpu.powerplay=1".

· Mejoras de escalabilidad en la gestión del espacio libre de Btrfs

Los sistemas de archivos necesitan mantener un registro de los bloques que están en uso y de los que no. También necesitan almacenar información sobre el espacio libre en algún lado, porque regenerarlo de cero cuesta demasiado. Btrfs ha tenido la capacidad de almacenar un caché del espacio libre desde 2.6.37, pero la implementación se ha convertido en un cuello de botella de escalabilidad en los sistemas de archivos grandes (+30T) y ocupados.

Esta versión incluye una nueva y experimental implementación del caché de espacio libre, que es más ligero y resuelve los problemas de escalabilidad citados. Este nuevo sistema es experimental, y no está activado por defecto. Puede ser activado con la opción de montaje -o space_cache=v2. La primera vez que se utilice esta opción, se creará el nuevo caché de espacio libre y se activará una bandera de sólo lectura (los kernels antiguos podrán leer, pero no escribir, al sistema de archivos). Es posible revertir el cambio y volver al caché antiguo (y eliminar la bandera de sólo lectura) utilizando la opción de montaje -o clear_cache,space_cache=v1.


· Soporte para el Undefined Behaviour Sanitizer de GCC (-fsanitize=undefined)

UBSAN (Undefined Behaviour SANitizer) es una herramienta de depuración disponible en GCC a partir de la versión 4.9 (ver -fsanitize=undefined documentation). Se trata de una funcionalidad que inserta código durante la compilación que hace comprobaciones en tiempo de ejecución para detectar situaciones que podrían causar comportamientos indefinidos. Comportamiento indefinido significa que las semánticas de ciertas operaciones no están definidas y el compilador asume que esas operaciones no se dan y que el programador se preocupará de evitarlas, pero de ocurrir la aplicación puede producir resultados equivocados, estrellarse, o incluso producir agujeros de seguridad; ejemplos de comportamientos indefinidos son el uso de una variable no estática antes de ser inicializada, división de un entero por cero, desbordamiento de enteros con signo, desreferenciación de punteros NULL, etc.


En esta versión, Linux soporte la posibilidad de compilar el kernel con la funcionalidad Undefined Behavior Sanitizer activada, con las opciones de -fsanitize: shift, integer-divide-by-zero, unreachable, vla-bound, null, signed-integer-overflow, bounds, object-size, returns-nonnull-attribute, bool, enum y, opcionalmente, alignment. La mayor parte del trabajo lo hace el compilador, el kernel se limita a mostrar los errores.

· Soporte de Forwarded Error Correction en el target verity del device-mapper

El target "verity" del device-mapper, utilizado por plataformas populares como Android o Netflix, fue incluido en Linux 3.4, y permite comprobar que un sistema de archivos no ha sido modificado, comprobando cada lectura del sistema de archivos con una lista de hashes criptográficos.

Esta versión añade soporte de Forward Error Correction para el target verity. Esta característica hace posible recuperarse de varios bloques de datos corrompidos, utilizando unos bloques pre-generados de correción de errores, que no ocupan demasiado espacio y pueden ser utilizados para reconstruir los bloques dañados. Esta técnica, utilizada en DVDs, discos duros o transmisiones satélite, permitirá seguir utilizando un sistema de archivos de un target verity que esté ubicado en un medio de almacenamiento que esté ligeramente dañado.

· Añadir la bandera MADV_FREE a madvise(2)

madvise(2) es una llamada al sistema utilizada por los procesos para decirle al kernel cómo van a utilizar su memoria, permitiendo al kernel, de ese modo, optimizar la gestión de memoria de acuerdo con las pistas proporcionadas, para alcanzar un mejor rendimiento del sistema.

Cuando una aplicación quiere decir al kernel que no va a utilizar un rango de memoria en un futuro cercano, puede usar la bandera MADV_DONTNEED, de manera que el kernel puede liberar los recursos de memoria asociados a ese rango. Los accesos subsiguientes tendrán éxito, pero sus consecuencia serán o bien recargar la memoria con datos del archivo mapeado, o páginas puestas a cero para los mapeados que no estén respaldados por archivos. Pero hay algunos tipos de aplicaciones (notablemente, asignadores de memoria de librerías) que pueden reusar ese rango de memoria, y MADV_DONTNEED fuerza a que incurran en el coste de hacer un fallo de página, asignación de una página, rellenarla con ceros, etc. Para evitar esa sobrecarga, otros sistemas operativos como los BSDs han soportado MADV_FREE, que simplemente marca las páginas como disponibles para ser liberadas, pero sin liberarlos inmediatamente, y por lo tanto permitiendo reusar la memoria en un corto espacio de tiempo sin incurrir en el coste de un fallo de página.

· Mejor escalabilidad multihilo en epoll

Cuando se añaden múltiples descriptores de archivo de epoll a una sóla fuente de eventos compartida entre todos, se añaden de modo que un evento puede despertar a todos los descriptores de archivo de epoll, lo cual crea un problema de escalabilidad cuando se utilizan muchísimos descriptores de archivo desde muchos hilos.

Esta versión añade una nueva bandera, EPOLLEXCLUSIVE, que puede pasarse como parte del argumento 'event' durante una operación EPOLL_CTL_ADD con epoll_ctl(2). Esta nueva bandera permite que las notificaciones de eventos no despierten a todos los descriptores de archivo. En una versión modificada de Enduro/X, el uso de la bandera 'EPOLLEXCLUSIVE' redujo la longitud de esta carga particular de 860s a 24s.

· La jerarquía unificada de cgroup se considera estable

cgroups, o grupos de control, son una característica introducida en Linux 2.6.24 que permite asignar recursos (como tiempo de CPU, memoria, ancho de banda) entre grupos de procesos definidos por el usuario. En su primera implementatión, los cgroups permitían un número arbitrario de jerarquías de procesos y cada jerarquía podía albergar cualquier número de controladores. Este modo de operar proporcionaba mucha flexibilidad, pero en la práctica tenía una serie de problemas, así que en Linux 3.16 se incluyó una uneva jerarquía unificada, pero experimental, y sólo disponible con la opción de montaje -o __DEVEL__sane_behavior.

En esta versión, la jerarquía unificada ya se considera estable, y ya no se esconde tras esa opción de montaje especial. Puede ser montada con el tipo de archivo cgroup2 (desgraciadamente, el controlador de cpu no ha llegado a ser incluído en esta versión, sólo los controladores de memoria y E/S están disponibles). Para mas detalles sobre cgroup2 y una justificación detallada sobre la migración a la jerarquía unificada, ver la documentación de cgroup2.

· Mejoras de rendimiento para sockets UDP que usen SO_REUSEPORT

SO_REUSEPORT es una opción de socket disponible desde Linux 3.9 que permite que múltiples sockets de escucha se "enganchen" al mismo puerto. La motivación tras el desarrollo de SO_REUSEPORT serían casos de uso tales como un servidor web escuchando en el puerto 80, y ejecutando múltiples hilos, cada uno con su propio socket.

En esta versión, Linux incluye dos optimizaciones para SO_REUSEPORT (en esta versión, sólo para sockets UDP):
  · Hay dos nuevas opciones de socket para sockets SO_REUSEPORT: SO_ATTACH_REUSEPORT_CBPF y SO_ATTACH_REUSEPORT_EBPF. Esas opciones permiten definir un programa BPF clásico o extendido, que defina cómo los paquetes se asignan a los sockets que están esperando en el grupo de sockets SO_REUSEPORT.
  · Búsqueda más rápida al seleccionar un socket SO_REUSEPORT para un paquete entrante. Anteriormente, el proceso de búsqueda necesitaba iterar por todos los sockets, en esta versión se puede encontrar un candidato mucho más rápido.

· Mejor gestión del uso de memoria de los sockets en el controlador de memoria

En anteriores versiones, los buffers de los sockets se contaban en el controlador de memoria de los cgroup por separado, sin ninguna presión que igualara entre la memoria anónima, el caché de páginas, y los buffers de sockets. Cuando se acababa la memoria de la reserva de buffers de socket, las asignaciones de buffers fallaban y el rendimiento de la red se hundía, al margen de que aun hubiera memoria disponible en el grupo o no. Del mismo modo, la memoria anónima u otros caches no podían hacer uso de la reserva para buffers de sockets que no estuviese siendo usada. Por esta razón, esta característica no podía ser usada con fiabilidad en muchas aplicaciones de la vida real.

En esta versión, el nuevo controlador de memoria unificado tendrá en cuenta todos los tipos de memoria a su cargo. Cuando haya poca memoria, la VM reclamará y reducirá y presionará en cualquier consumidor de memoria. Cuando la VM tenga problemas liberando memoria, la pila de red detendrá los incrementos en los "transmit windows" del cgroup. Para evitar la gestión de memoria de los sockets de buffer, es posible usar la opción del kernel cgroup.memory=nosocket.



Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.

Las novedades de Linux 4.4

Ya se ha anunciado la versión 4.4 de Linux. Esta versión añade soporte 3D para el driver de la GPU virtual, que permite usar la aceleración 3D de hardware en sistemas virtualizados; se añade también soporte de E/S directo y asíncrono en el dispositivo loop, lo cual ahorra memoria y mejora el rendimiento; se añade soporte para discos SSDs Open-Channel, que son SSDs que intentan compartir con el sistema operativo la responsabilidad de la FTL; la gestión de los "TCP listener" se hace ahora sin ningún tipo de bloqueo y permite que los servidores TCP sean más rápidos y mucho más escalables; journaling de RAID5 en la capa MD que permite solucionar el llamado "write hole"; los programas eBFP pueden ahora ser ejecutados por usuarios sin privilegios, pueden hacerse permanentes tras el fin de un proceso, y la utilidad perf ha añadido soporte para eBFP también; una nueva llamada de sistema mlock2() que permite bloquear la memoria añadida desde los fallos de página; y soporte de polling en dispositivos de bloques que mejora el rendimiento en los dispositivos de muy alto rendimiento. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.


· Dispositivo loop más rápido y ligero con E/S Directa y Asíncrona

  Esta versión incorpora soporte de E/S directa y asíncrona en el dispositivo de bloques loop. Esto tiene varias ventajas: se mejora el consumo de memoria porque se evita mantener un cache duplicado; y se mejora el rendimiento al evitarse cambios de contexto

· Soporte en el driver de GPU virtual

  virtio-gpu es un driver para huéspedes de virtualización que permite utilizar las capacidades gráficas del anfitrión eficientemente. En esta versión, se permite que el huésped utilice las capacidades de la GPU del anfitrión para acelerar los gráficos 3D. En la práctica, esto significa que un huésped virtualizado Linux puede ejecutar juegos OpenGL utilizando la GPU, como se muestra aquí o aquí. Se requiere el uso de QEMU 2.5 o superior.

· LightNVM añade soporte para SSDs Open-Channel

  Los SSDs Open-Channel son dispositivos que comparten con el sistema operativo la responsabilidad de implementar y mantener las características que los SSDs implementan típicamente en el firmware, tales como la Flash Translation Layer (FTL), la gestión de bloques dañados, y unidades del hardware como el controlador flash, el controlador de la interfaz, y muchos chips flash. De este modo, los SSDs Open-Channel exponen un acceso directo al almacenamiento físico flash.

LightNVM es una especificación que da soporte a SSDs Open-Channel. LightNVM permite al sistema gestionar la ubicación de los datos, la recolección de memoria y el paralelismo, mientras que otras características permanecen en control del hardware. Esta versión de Linux añade soporte para lightnvm y para NVMe.

· Gestión de TCP listeners sin bloqueos

  En esta versión, y como resultado de un esfuerzo que empezó hace dos años, la implementación TCP ha sido reescrita para que no haya ningún bloqueo en las rutas más comunes del código que gestiona a los programas que hacen escuchas TCP. En pruebas, un servidor fue capaz de procesar 3.500.000 de paquetes SYN por segundo en un sólo listener y sin llegar a ocupar todo el tiempo de CPU, esto representa entre 2 y 3 órdenes de magnitud de lo que era posible previamente. SO_REUSEPORT también ha sido extendido para añadir afinidades de CPU/NUMA.

· Soporte de journalled RAID5 en MD

  Esta versión añade soporte de RAID 5 journalled en la capa MD (RAID/LVM). Con un dispositivo de journal configurado (típicamente NVRAM o SSD), los datos y la paridad de un array RAID se escriben primero al journal, y luego al array. Si el sistema se bloquea, se pueden recuperar datos del log. Esto puede acelerar la resincronización RAID y resuelve el problema del "write hole" de RAID5 - un cuelgue durante el modo degradado no resultará en corrupción de datos. En futuras versión el journal será utilizado también para mejorar el rendimiento y la latencia.

· Programas eBPF sin privilegios + programas eBPF persistentes

  Programas eBPF sin privilegios
  Los programas eBPF consiguieron su propia llamada al sistema en Linux 3.18, pero hasta ahora su uso había estado restringido a root, porque estos programas son peligrosos para la seguridad. Sin embargo, los programas eBPF son validados por el kernel, y en esta versión el verificador de programas eBPF ha sido mejorado y como resultado los usuarios sin privilegios pueden hacer uso de ellos (aunque sólo podrán construir programas tipo filtro de sockets, los programas que usen funciones de trazado o del control de tráfico de red requerirán root). esta característica puede ser desactivada con la sysctl kernel.unprivileged_bpf_disabled (una vez desactivada sólo root podrá usar programas eBPF, y la sysctl no podrá volver a cambiarse)

  Programas eBPF persistentes
  Esta versión añade soporte para mapas/programas eBPF "persistentes". El término "persistente" ha de entenderse como un mecanismo que permite que sobrevivan al fin del proceso que los crea. Hay usuarios eBPF que desean este tipo de comportamientos, por ejemplo el clasificador de tráfico tc(8). Cuando tc hace uso de un objecto eBPF, nuevas invocaciones de tc no podrán reutilizarlo.

  Para solucionar ese problema, se ha añadido un sistema de archivos virtual que puede almacenar programas y mapas eBPF en /sys/fs/bpf/. Los objetos eBPF son creados mediante la llamada al sistema bpf() junto con una ruta y dos nuevos comandos (BPF_OBJ_PIN/BPF_OBJ_GET) que crean los archivos correspondientes en el sistema de archivos. Estos archivos pueden ser reutilizados posteriormente por otros procesos, a través también de bpf(2).

· Integración de perf y eBPF

  En esta versión, los programas eBPF han sido integrados en perf. Cuando se pasa a perf un archivo .c eBPF (o uno .o compilado con el target "bpf" de clang) será compilado automáticamente, validado y cargado en el kernel, pudiendo ser utilizado posterioemente por perf trace y otras herramientas.

  Los usuarios pueden hacer uso de un filtro eBPF con comandos como: # perf record --event ./hello_world.o ls; y el programa eBPF será conectado a un evento perf que puede ser utilizado por el resto de herramientas.

· Soporte de polling para dispositivos de bloque

  Esta versión añade soporte básico para hacer polling para que una petición de E/S concreta se complete, lo cual puede mejorar la latencia y el rendimiento en dispositivos muy rápidos. De momento, se soportan escrituras y lecturas síncronas con O_DIRECT. Este soporte es preliminar y sólo debe ser utilizado para pruebas, en próximas versiones se utilizarán estadísticas para hacer uso de este modo automáticamente. De momento, se añade un archivo en sysfs (io_poll) que controla si el polling está activado o no.

· Llamada al sistema mlock2() que permite a los usuarios bloquear memoria en fallos de página

  mlock() permite a un usuario bloquear la memoria de un programa en la RAM, pero esto tiene como coste la necesidad de incluir en la RAM toda la memoria de una vez. Este comportamiento no es muy adecuado cuando se necesita usar mlock() con mapeados de archivos muy grandes: Por ejemplo, las aplicaciones sensibles con la seguridad que usan mlock() pueden verse forzadas a bloquear un búfer demasiado grande. O quizás un modelo gráfico gigantesco donde la ruta de un grafo no es conocida hasta el tiempo de ejecución, en lugar de bloquear en memoria sólo las partes utilizadas están forzadas a bloquear todo el grafo o ir bloqueando página tras página a medida que van siendo utilizadas.

Esta nueva llamada al sistema, mlock2(), trata de conseguir una solución intermedia. Las páginas de la memoria no son bloqueadas en memoria inmediatamente, sino que se van bloqueando aquellas que van siendo mapeadas en memoria.

Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.

Las novedades de Linux 4.0

Ya se ha anunciado la versión 4.0 de Linux. Esta versión añade soporte para parchear el kernel en vivo, con el objetivo principal de corregir fallos de seguridad sin reiniciar; también se añade DAX, un sistema para evitar utilizar el cache del kernel cuando los sistemas de archivo funcionan en sistemas con almacenamiento de memoria persistente; kasan, un detector de errores de memoria de use-after-free y out-of-bounds; lazytime, una alternativa a relatime, que provoca que las modificaciones a los metadatos de archivos como atime se hagan sólo en cache y se escriban al disco de modo oportunista para mejorar el rendimiento; overlayfs añade soporte para tener múltiples capas inferiores; se añade soporte de Parallel NFS; y dm-crypt tiene importantes mejoras de escalabilidad. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.


· Cambio de versión completamente abitrario

Esta versión incrementa la versión a 4.0. Esta cambio de 3.x a 4.0 no tiene ningún significado particular y no debe ser asociado con ningún cambio técnico de relevancia en el kernel. Esta versión podía haber sido la 3.20, pero Linus Torvalds se cansó del numero 3, hizo una encuesta, y lo cambio. Si, es frívolo. Cuanto menos piense sobre ello, mejor. 


· Parcheado en vivo

Esta versión incluye "livepatch", una caraterística que permite parchear el código del kernel en tiempo de ejecución, y que está orientada fundamentalmente a aquellas personas que quieran tener actualizaciones de seguridad sin necesidad de reiniciar. Esta característica nació como resultado de la fusión de kgraft y kpatch, dos intentos de SuSE y Red Hat que fueron iniciados para reemplazar el ahora propietario ksplice. Es relativamente simple y minimalista, y hace uso extensivo de infraestructura ya existente en el kernel (ftrace). El código está contenido en su propio directorio y no necesita "enganches" en el resto de subsystemas.

En esta versión livepatch no está completo, pero ya proporciona soporte para parchear funciones, incluye una API para los módulos del kernel que contengan los parches, y una API/ABI para espacio de usuario que permite operar los parches (ver cuáles están activos, activarlos, desactivarlos, etc). La mayoría de los CVEs pueden aplicarse de este modo. En esta versión sólo se soporta la arquitectura x86, otras llegarán en futuras versiones.


· DAX, acceso directo para sistemas con almacenamiento de memoria persistente

Antes de que sean leídos por los programas, los archivos se copian primero a los caches del kernel, que se encuentran en la memoria RAM. Pero es posible que en los próximos años se popularicen los sistemas basados en la llamada "memoria persistente", que proporcionan enormes cantidades de almacenamiento con velocidades de acceso equivalentes a la memoria RAM y mantendrían los contenidos a pesar de cortes de energía. En estos sistemas, no habría una separación RAM-disco, sino que la memoria persistente es al mismo tiempo memoria RAM y espacio de almacenamiento. En una arquitectura así, los caches del kernel son redundantes.

Linux ha tenido cierto soporte para este tipo de sistemas desde 2.6.13. Pero el código no estaba siendo mantenido y sólo soportaba ext2. En esta versión, Linux añade una nueva implementación llamada DAX. DAX elimina la copia extra de los caches haciendo que las lecturas y escrituras se hagan directamente almacenamiento de memoria persistente. En esta versión se añade soporte para ext4.


· kasan, detector de errores de gestión de memoria en el código

Kernel Address sanitizer (KASan) es un detector de errores que detecta bugs use-after-free y out-of-bounds bugs. Linux ya tiene kmemcheck, pero a diferencia de kmemcheck, KASan utiliza instrumentación en tiempo de compilado, lo cual lo hace significativamente más rápido que kmemcheck.

La idea principal de KASan es almacenar información sobre la seguridad de acceder cada byte de memoria o no, y usar la instrumentación del compilador para comprobar esa información en cada acceso de memoria. KASan utiliza 1/8 de la memoria direccionable por el kernel para mantener esta información. 


· lazytime para una actualización de los tiempos de un archivo más eficiente

Los sistemas Unix mantienen información variada sobre los archivos, tal y como la última vez que un archivo fue accedido o modificado. Mantener esta información es costoso, especialmente la información sobre cuándo fue accedido un archivo por última vez ("atime"), que animó a mucha gente durante mucho tiempo a desactivar la actualización de ese campo con la opción "noatime". Para aliviar este problema se añadió la opción "relatime", que sólo modificaba el campo atime si el archivo había sido modificado hace más de 24 horas. Este comportamiento, sin embargo, provoca errores en ciertos programas que requieren una actualización precisa de atime, y además va en contra del estándar POSIX.

En esta versión, Linux añade otra alternativa, "lazytime". Lazytime hace que los tiempos de acceso, modificación y cambio se hagan sólo al cache. Los tiempos serán sólo escritos al disco si el inodo es actualizado por otra razón, o si se utilizan llamadas al sistema como fsync(), syncfs() o sync(), o antes de que el caché del inodo vaya a eliminarse de la memoria. Esta manera de funcionar está de acuerdo con POSIX, hace funcionar a los programas que rompía "relatime", y, además, mejora el rendimiento.


· Múltiples capas inferiores en overlayfs

En overlayfs, ahora es posible especificar múltiples capas inferiores. Para hacerlo, se puede utilizar los dos puntos (":") como separador entre los diferentes directorios. Por ejemplo:

     mount -t overlay overlay -olowerdir=/lower1:/lower2:/lower3 /merged

Los directorios inferiores especificados se apilarán uno encima del otro desde el de la derecha al de la izquierda. En el ejemplo anterior lower1 estará arriba del todo, lower2 en el medio y lower3 abajo. "upperdir" y "workdir" pueden omitirse, aunque en ese caso el overlay será de sólo lectura.


· Soporte de servidor de Parallel NFS, NFS v4.2 por defecto

Parallel NFS (pNFS) es parte del estándar NFS v4.1 que permite a los clientes acceder a dispositivos de almacenamiento directamente y en paralelo. La arquitectura pNFS elimina los problemas de escalabilidad y rendimiento asociados con los servidores NFS hoy. Esto se logra mediante la separación de datos y metadatos, y moviento los servidores de metadatos fuera de la ruta principal de acceso a los datos.

Esta versión añade soporte para tener un servidor pNFS en Linux, y se proporcionan drivers para el layout "block", junto con el soporte para utilizar ese layout en sistemas de archivo XFS. También se añade el layout "flexfiles".

Además, en esta versión la versión por defecto del servidor NFS será NFS v4.2.


· Mejoras de escalabilidad de dm-crypt

Esta versión incrementa significativamente el rendimiento y escalabilidad de CPU de dm-crypt, gracias a unos cambios que permiten un uso más efectivo de todas las CPUs. Los resultados de una serie de tests y benchmarks pueden encontrarse aquí.

Y eso es todo. La lista completa de cambios en inglés, aquí.