22 de julio de 2012

Las novedades de Linux 3.5

Ya se ha anunciado la versión 3.5 del kernel Linux. Esta versión incluye soporte de checksums de los metadatos en Ext4, "sondas" de rendimiento en programas de espacio de usuario (uprobes), un mecanismo simple para construir sandboxes filtrando llamadas al sistema, un nuevo algoritmo de gestión de la cola de red diseñado para luchar contra el mal de las redes llamado "bufferbloat", soporte para detener y restaurar conexiones TCP, soporte del RFC 5827 ("TCP early retransmit"), soporte para la "suspensión del sistema oportunista" al estilo de Android, conteo de las estadísticas de fallos de E/S en Btrfs, y la capacidad de usar SCSI sobre Firewire y USB. 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. 

· Checksums en los metadatos de Ext4: Los sistemas de archivo como ZFS y Btrfs han probado que asegurar la integridad del sistema de archivos mediante checksums es algo que merece la pena. Así que Ext4 ha añadido la capacidad de almacenar checksums para todos los metadatos del sistema de archivos (no cubre los datos, ni tiene capacidades de "auto-curación").

Cualquier sistema de archivos Ext4 puede ser actualizado para aprovechar esta nueva característica utilizando el comando "tune2fs -O metadata_csum", o "mkfs -O metadata_csum" cuando se crea. Una vez que esta característica sea activada, los kernels antiguos que no la soportan sólo podrán montar el archivo en modo de sólo lectura.

Respecto al rendimiento, no es notable en la mayoría de casos comunes, sólo en casos orientados exclusivamente al manejo de metadatos, que son muy poco comunes.

· uprobes ("sondas" en espacio de usuario): uprobes es la contraparte de kprobes en espacio de usuario. Este sistema permite colocar "sondas" en cualquier dirección de memoria de un programa, y coleccionar información para encontrar problemas de rendimiento o para hacer simples mediciones. Estas sondas pueden colocarse dinamicamente en cualquier proceso, no se necesita reiniciar el programa ni modificar los binarios. Las sondas normalmente son gestionadas con herramientas de instrumentación como "perf probe", systemtap o LTTng. Un ejemplo de uso de uprobes con perf podría ser medir el uso de las llamadas a malloc() en la libc:

$ perf probe -x /lib64/libc.so.6 malloc 
Added new event:
probe_libc:malloc    (on 0x7eac0)

Se ha colocado una sonda en la dirección de la función malloc. Ahora, vamos a grabar el uso global de malloc en todo el sistema durante un segundo:
 
$ perf record -e probe_libc:malloc -agR sleep 1

Ahora puedes ver los resultados con la interfaz TUI con el comando "$ perf report", o ver una salida en texto plano en la salida estándar con "$ perf report -g flat --stdio". Si no sabes qué función quieres sondear, puedes conseguir una lista de las funciones sondeables en librerías y ejecutables usando el parámetro -F, por ejemplo: "$ perf probe -F -x /lib64/libc.so.6" o "$ perf probe -F -x /bin/zsh". Se pueden utilizar múltiples sondas y mezclaras con kprobes y con los eventos PMU del hardware o los tracepoints del kernel.

El código de uprobes es uno de los parches que más tiempo lleva fuera del kernel. Se originó a partir de SystemTap, y se ha incluido durante años en los kernels de Red Hat y Fedora.

· Filtrado de llamadas al sistema basado en seccomp: seccomp (alias de "secure computing") es un sistema simple para sandboxear procesos que fue añadido en 2.6.12 y que permite que los procesos puedan cambiar a un estado en el que sólo pueden usar un conjunto de llamadas al sistema muy limitado (exit, sigreturn, y read y write para descriptores de archivo ya abiertos). Seccomp ha sido extendido, y ahora permite construir filtros arbitrarios de llamadas al sistema, lo cual permite implementar diferentes tipos de mecanismos de seguridad. Por ejemplo, el navegador Chromium soporta esta característica para ejecutar plugins en una sandbox.

El demonio de inicio de sistema SystemD ha añadido soporte para esta característica. Un archivo de una unidad puede usar SystemCallFilter para especificar una lista de las únicas llamadas al sistema que podrán ser utilizadas, por ejemplo:

[Service] 
ExecStart=/bin/echo "I am in a sandbox"
SystemCallFilter=brk mmap access open fstat close read fstat mprotect arch_prctl munmap write

· Lucha contra el bufferbloat: gestion de cola CoDel: CoDel (alias de "controlled delay") es un algoritmo de gestión de cola de red que ha sido diseñado para luchar contra los problemas de exceso de buffering a lo largo de toda una ruta de red, problemas conocidos como "bufferbloat". De acuerdo con Jim Gettys, que fue quien acuñó ese término, "este trabajo es la culminación de tres intentos para resolver los problemas de los algoritmos de gestión de colas durante los últimos 14 años".

· Reparación de conexiones TCP: Como parte de los esfuerzos para implementar el checkpointing/restauración de procesos, Linux añade soporte para parar una conexión TCP y reiniciarla en otro host. Las implementaciones de virtualización ligera de contenedores usan esto para migrar toda una conexión de un host a otro de forma transparente, sin que lo note la otra parte de la conexión. Esto se consigue poniendo al socket en un modo de "reparación" que permite conseguir la información necesaria para restaurar ese estado en un socket nuevo.

· TCP Early Retransmit (RFC 5827): Esta funcionalidad permite activar la "retransmisión rápida" de paquetes en ciertas condiciones, para reducir el número de ACKs duplicados. En otras palabras, las conexiones se recuperan de paquetes perdidos antes, lo cual mejora la latencia.

· Suspensión oportunista del sistema al estilo Android: El problema más controvertido en la inclusión de código de Android en Linux es la funcionalidad llamada "suspend blockers" o "wakelocks". Son parte de una aproximación a la gestión de energía consistente en suspender el sistema lo más posible. El estado natural del sistema es la suspensión, utilizando energía sólo para refrescar la memoria y para poder volver a despertar de nuevo. El sistema sólo se activa de verdad cuando tiene trabajo que hacer, y en cuanto termina, vuelve a suspenderse.

Esta es una buena idea, pero a los desarrolladores del kernel no les gustó la implementación de Android (se puede encontrar un análisis técnico del problema aquí). Ha habido muchos flames, y poco progreso, lo cual es un gran problema porque los drivers de Android usan las APIs de los "suspend blockers", y la ausencia de dichas APIs hacía imposible incluir el código en Linux. Pero en esta versión, el kernel incorpora una funcionalidad similar llamada "autosleep y wake locks". Se espera que pueda servir a Android y que la inclusión de drivers de él se acelere.

· Estadísticas de fallos de E/S en Btrfs y mejoras de latencia: Se ha añadido soporte para la recolección de estadísticas de fallos de E/S en Btrfs para cada unidad. El comando de Btrfs para recabar esa información, que será incluido en futuras versiones de btrfs-progs, es "btrfs device stats".

Esta versión de Btrfs también incluye cambios que hacen que Btrfs sea mucho más amigable con el reclamado de memoria, y reduce bastante las latencias para E/S síncrono.

· SCSI sobre Firewire y USB: Esta versión incluye un driver que permite usar una conexión Firewire como transporte SCSI. Esto permite exponer dispositivos SCSI a otros nodos en el bus Firewire: por ejemplo, discos duros. Es una funcionalidad similar al Target Disk mode de los ordenadores Apple.

Esta versión también incluye un driver usb-gadget que hace lo mismo con USB. El driver soporta dos protocoloes USB: BBB/BOT (Bulk Only Transport) y UAS (USB Attached SCSI).

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

No hay comentarios:

Publicar un comentario en la entrada