Novedades en systemd, IV

Lennart Poettering escribe artículos explicando las novedades en systemd. Parece que yo he venido a hacer lo mismo con resúmenes en español - que hago porque systemd es francamente interesante y proporciona a administradores y usuarios capacidades que todos deberían conocer. Así que he aquí esta nueva entrega de las noticias de systemd en los últimos meses (continuación de esta serie de posts) 

Estandarización de /etc

En primer lugar, han decidido intentar estandarizar tanto en ruta como en formato varios archivos de configuración básicos de /etc. Esta es una de esas cosas sencillas de hacer y de mero sentido común (¿de verdad es necesario que el archivo en el que se almacena el hostname tenga una ubicación diferente en cada distro?) que por puro politiqueo no se ha logrado hacer jamás. Para que luego digan que a Lennart Poettering le gusta romper cosas, systemd lee en primer lugar los archivos designados por la nueva estandarización, pero de no existir también soporta las divergencias individuales de cada distro, en caso de que aun no se hayan actualizado o no pretendan hacerlo.

Como consecuencia lógica de lo anterior, también pretende acabar a largo plazo con la diferencia entre /etc/sysconfig/* (RedHat/Suse) y /etc/default/* (Debian y derivados), aunque en este caso la pretensión no es de unificarlos sino directamente eliminar ambos, ya que la mayoría de lo que hay en ellos es inútil con la presencia de systemd, y lo restante no tiene sentido o no debería estar ahí. De nuevo, un cambio simple y de sentido común pospuesto durante demasiados años. 


Servicios instanciables

Algunos servicios, como CUPS o syslog, suelen tener una sola instancia funcionando en todo momento (nadie necesita dos syslogs funcionando simultáneamente). Existen, por contra, otros servicios que suelen instanciarse varias veces: un fsck para cada sistema de archivos a montar, un getty en cada terminal virtual. A estos últimos systemd los denomina "servicios instanciados" (yo prefiero "instanciables").

Para los servicios instanciables, systemd propone el uso de "plantillas" que permiten crear instancias desde la misma línea de comandos. Citando el ejemplo del enlace, existe una plantilla llamada serial-getty@.service, la cual puede recibir "objetivos" a instanciar como parámetros:

[Unit]

Description=Serial Getty on %I

BindTo=dev-%i.device

After=dev-%i.device systemd-user-sessions.service

[Service]

ExecStart=-/sbin/agetty -s %I 115200,38400,9600

De modo que el comando $ systemctl start serial-getty@ttyUSB0.service arrancará un getty en ttyUSB0. Y en el listado de servicios aparecerá cada instancia del servicio con su nombre. Y se puede detener la creación de nuevas instancias, desactivando la plantilla, sin que eso requiera detener las instancias ya iniciadas.

Este mecanismo permite hacer cosas muy curiosas. Mezclándolo con la capacidad de systemd de recibir conexiones a un puerto y pasar el socket abierto a otro programa, al estilo xinetd, Lennart propone que sshd sea un servicio instanciable. De ese modo, cada sesión ssh será una instanciación, y en el listado de servicios aparecerán todas las instancias, con la IP y puerto del usuario conectado como parte del nombre de cada instancia.

Otro ejemplo de estos servicios instanciables es como, en Fedora, han llegado al extremo de que, por defecto, en el arranque se inicia solamente un getty, el correspondiente a la tty1. Cuando el usuario pulsa (Ctrl+)Alt+F2, se instancia automáticamente el getty de tty2, pero no antes. De ese modo, el sistema se ahorra tener que configurar e iniciar preventivamente esos gettys.


Aislamiento de servicios

Linux soporta desde hace tiempo la capacidad de limitar varias capacidades de los procesos: aislarlo de la red, del resto de sistema de archivos, etc. Sin embargo, esta funcionalidad rara vez se usa. Con systemd, basta añadir una línea en la configuración del servicio. Por ejemplo, para que un servicio no pueda acceder a ningún tipo de interfaz de red presente en el sistema, basta añadir "PrivateNetwork=yes". He aquí una lista de capacidades de aislamiento, copiada del post de Lennart:

 · Aislar un servicio de la red: PrivateNetwork=yes

 · Proporcionar un /tmp virtual privado para el servicio: PrivateTmp=Yes

 · Prohibir acceso a directorios determinados: InaccessibleDirectories=/home /foo

 · Permitir el acceso a un directorio en modo de sólo-lectura: ReadOnlyDirectories=/var /bar

 · Limitar el número de subprocesos o, directamente, prohibir hacer fork(): LimitNPROC=1

 · Limitar el tamaño de los archivos, o incluso prohibir escribir nada: LimitFSIZE=0

 · Prohibir el acceso a todos los nodos de dispositivo de /dev excepto /dev/null: DeviceAllow= /dev/null rw

 · Limitar las capabilities de un proceso, por ejemplo, prohibir el uso de las interfaces de ptrace: CapabilityBoundingSet=~CAP_SYS_PTRACE


Y esto es todo, a falta de más novedades. Si algunos admiramos a Lennart Poettering y rechazamos las críticas que se le hacen no es por capricho: se trata de un programador excepcional que crea software excepcional.

La oportunidad de Ubuntu TV

En su día dejé a Ubuntu por Fedora, pero nunca hice ese cambio porque Ubuntu me pareciera mala distro (a diferencia de cuando dejé Debian), sino porque Fedora me parecía mejor. Con esto quiero decir que sigo considerando a Ubuntu la mejor distro Linux de escritorio en general, y a Canonical la Red Hat del escritorio.

Especialmente importante me parece el último punto, que Canonical sea como Red Hat. Como he defendido otras veces aquí, el éxito de Linux en el escritorio o en cualquier lado no puede basarse sólo en gente que contribuye en su tiempo libre. Es un crítico que existan empresas grandes, rentables y prósperas dispuesta a contratar a jornada completa a unos cuantos programadores, como Red Hat o Suse hicieron en servidores. Solo así es posible ser competitivos.

Y, en ese sentido, Ubuntu TV me parece una gran noticia, aunque técnicamente no esa "escritorio Linux".

Si, es cierto que sólo se ha presentado el software, y que ningún fabricante de televisiones se ha dignado a pasarse por allí para mostrar algún prototipo. También es cierto que Ubuntu TV podría quedarse en fracaso si no aparece ninguno. Y no es menos cierto que Ubuntu carece de lazos con las grandes multinacionales distribuidoras de contenidos (que en realidad es el mayor problema). Ah, y no olvidemos que Ubuntu es un objetivo potencial de los ataques monopolistas de las patentes de software.

Pero Ubuntu TV tiene una ventaja, y es que existe. Las "televisiones inteligentes" no son nuevas, tampoco lo son los tropecientos mil softwares y hardwares para Media Center. Sin embargo, se espera que haya un boom en el campo. Y el mero hecho de existir y estar ahí puede dar a Ubuntu TV la oportunidad de ser utilizado por un fabricante desesperado por no quedarse atrás, o uno que quiera probar varias opciones para saber cuál gusta más a sus clientes.

Cuando la aparición del iPhone hizo que los teléfonos táctiles se convirtieran en el estándar, el mero hecho de "estar ahí" fue fundamentalmente lo que acabó dando a Android el puesto de primer SO para smartphones. De haberse dado Microsoft más maña, hubieran sido ellos los ganadores. No sé hasta qué extremo llegará el tema de las televisiones inteligentes, ni cómo se acabará interactuando con ellas, ni si las distribuidoras de contenidos se han decidido ya a permitir a la gente pagar por contenidos o quieren seguir forzándoles a usar Megaupload descargas ilegales. Pero Ubuntu TV está ahí, y gracias a eso podrá tener una oportunidad.

Incluso si fracasa estrepitosamente y Ubuntu TV desaparece, el mero hecho de haber intentado anticiparse marca una diferencia fundamental con la que ha sido la tradición linuxera en la informática de consumo, que consistía en llegar mal y tarde a las novedades tecnológicas, y lloriquear porque las multinacionales privativas acaparaban todo.

Y si Ubuntu TV tiene algo de éxito, imagínense: podran ganar dinero y reinvertirlo. Quien sabe, incluso podrían hacer algo que contente a los críticos con Unity.

Windows y su nuevo sistema de archivos, ReFS

Microsoft ha publicado algunos detalles sobre un nuevo sistema de archivos, ReFS, "Resilient filesystem". Resumiendo mucho, se trata de un "ZFS para Windows" (pero hay matices que comentaré en este post que, para cambiar un poco, es sobre una noticia de hoy). Es más, mirando fechas no hay que ser un genio para darse cuenta de que fue desarrollado tras la aparición de ZFS y con el propósito de imitarle.

Lo cual no viene más que a confirmar una vez más el enorme impacto que ha tenido y sigue teniendo ZFS. Si tenemos en cuenta que para desarrollar y estabilizar un sistema de archivos son necesarios unos cuantos años, lo que se ha vivido en los últimos 7 años que han pasado desde que apareció ZFS es en realidad una revolución repentina y violenta en el mundillo: ha obligado a todo el mundo a desechar miles de líneas de código de una de las partes más críticas que hay en un sistema operativo, y reimplementarlo de cero.

ReFS merece, sin embargo, algunos comentarios. Teniendo en cuenta lo poquísimo que se puede comentar sobre un sistema de archivos de Microsoft, de los que nunca se sabe casi nada. Ni tan siquiera existe buena documentación pública sobre NTFS.

· Si leen el blog de Microsoft, verán que se afirma que no es una reescritura completa de NTFS, sino una reescritura de su "motor de almacenamiento". Esta afirmación puede llevar a pensar que se ha reescrito sólo "la parte de NTFS que escribe cosas al disco". Mi opinión es que esta idea se trata de una confusión: La diferenciación conceptual clara entre "VFS" y "sistema de archivo" es una noción muy linuxera. En Linux el VFS implementa, por ejemplo, la gestión del caché, y todos los sistemas de archivos lo reutilizan. En NTFS (o en ZFS) el "sistema de archivos" suele implementar casi todo por su cuenta (nadie soporta tantos sistemas de archivos como Linux, así que no tienen tantos incentivos para generalizar y reusar esas partes). Por eso, lo que Microsoft llama "cambio del motor de almacenamiento", en Linux se llamaría "nuevo sistema de archivos".

 · Al igual que Btrfs, parece que han escogido un espacio de direccionamiento de 64 bits, y no de 128 bits, como hizo ZFS. Que, en realidad es lo más lógico. Los 128 bits de ZFS son una exageración que quizás ZFS nunca llegue a necesitar. La verdad es que tampoco es tan importante, tanto 64 como 128 bits son una barbaridad.

· ReFS utiliza, como es de esperar en cualquier derivado de ZFS, técnicas de "copy-on-write" ("allocate-on-write", lo llaman ellos): Cuando se cambia algo, en lugar de escribir sobre los bloques que contienen los datos viejos, lo que se hace es escribir en bloques vacíos. Una vez escritos, las estructuras de datos que apuntaban a los datos viejos se modifican -también, a su vez, usando "copy-on-write"- para que apunten a los nuevos.

· Es curioso, sin embargo, que por defecto, cuando se utilice un sólo disco, ReFS no utilizará copy-on-write en los datos y, aparentemente, tampoco checksums, sólo en los metadatos. Se activarán por defecto sólamente con múltiples discos, en discos únicos habrá que hacerlo manualmente, en el formateo. Es decir, en configuraciones unidisco ReFS será, por defecto, equivalente a Btrfs montado con las opciones "nodatacow" y "nodatasum". Sin embargo, será posible activar ambas características manualmente para archivos y directorios determinados (Btrfs también permite desactivar esas características a nivel de archivo). Para ello, las aplicaciones, o los usuarios, tendrán que marcar un archivo como "integrity stream".

· Como ZFS, ReFS soporta "scrubbing", es decir, un proceso de validación de todos los checksums del sistema de archivos. Sin embargo, las aplicaciones podrán deshabilitar el scrubbing para un archivo determinado, del mismo modo que se desactiva el "integrity stream".

· ReFS utiliza una estructura de árbol, para representar en el disco todos los metadatos. Se utiliza la implementación del árbol lo mismo que un roto que para un descosido: un árbol puede almacenar un listado de directorios, otro puede almacenar la lista de extents de un archivo, y los nodos en los árboles que pueden apuntar a otros árboles.

· Sin embargo, no conocemos detalles de la implementación del B+Tree de ReFS. Btrfs utiliza una estructura de datos creada de un trabajador de IBM, que lo diseñó explícitamente para crear un sistema de archivos tipo ZFS (a quien le gusten las discusiones de estructuras de datos y algoritmos puede echarle un ojo). La verdad, no tengo ni idea de si la implementación de ReFS será mejor, peor, o incluso una copia disimulada. Y nunca lo sabremos, porque Microsoft nunca llegará a este nivel de detalle.

· Aunque parezca sorprendente, ReFS no parece implementar por si mismo ningún tipo de capacidad de replicación de datos o metadatos, ni de gestión de múltiples discos en forma de "pool". Quien lo implementará será "Storage Spaces", un gestor de volúmenes que verá la luz en Windows 8 y que implementará esas funciones tanto para NTFS tradicional como para ReFS.

· Por ello sospecho (aunque no puedo asegurar) que a diferencia de ZFS y Btrfs, que han reescrito de cero su propio gestor de volúmenes, Microsoft ha decidido extender su gestor de volúmenes para implementar nuevas características. No estoy seguro del alcance de esta decisión: en Linux también podrían haberse implementado algunas características de ZFS extendiendo Ext3 y LVM, y Btrfs podría haberse implementado sobre ese LVM mejorado. No se hizo así, pero Microsoft parece haber intentado esa vía.

· Probablemente como consecuencia de lo anterior, y a falta de más detalles, parece ser que ReFS es incapaz de duplicar metadatos dentro de una misma partición, como si hacen ZFS y Btrfs. Es más, no parece que a la hora de duplicar ReFS permitirá diferenciar entre replicación de datos y de metadatos. En una misma partición ReFS detectará corrupciones de metadatos gracias a los checksums, pero si los Storage Spaces no tienen configurados varios discos para mirroring no se podrá acceder a otra copia, y parte del sistema de archivos se volverá inservible (por esa razón ZFS y Btrfs duplican los metadatos incluso en una misma partición).

· Una característica curiosa de ReFS: Si gracias a los checksums se detecta corrupción en alguna parte del disco que no se puede corregir, bien por ausencia de copias, bien por corrupción que se ha expandido a todas las copias, se puede hacer un proceso llamado "salvage" ("salvamento"), que consiste en descartar las partes dañadas. Pongamos, por ejemplo, que el directorio C:/FOO está corrupto, pues el proceso de "salvage" se carga ese directorio dañado a lo bestia.

· Algunas características como enlaces duros no estarán disponibles. Pero no estarán disponibles no porque no les haya dado tiempo a implementarlas, sino por eleccion. La verdad, no entiendo el por qué.

· ReFS sólo estará disponible en Windows 8 Server, y no se podrá instalar Windows sobre él. Teniendo en cuenta que se sabe que Apple está diseñando un nuevo sistema de archivos que seguramente tendrá características de ZFS, añado a mis predicciones para 2012/13 que veremos un OS X con nuevo sistema de archivos y características de ZFS antes de que ReFS llegue a los Windows de escritorio.

FreeBSD 9.0 y el retorno de softupdates

Ya ha salido FreeBSD 9.0, lo cual quiere decir que es un momento propicio para renovar mi gratuito e injustificado desdén linuxero hacia los BSDs.

Aunque en los foros los usuarios de FreeBSD suelen nombrar a ZFS como una ventaja de usar FreeBSD, y con razón, hay que recordar que desde el punto de vista de los desarrolladores la cosa cambia. La mayoría de ellos son militantes que creen que la licencia BSD es la mejor y sienten desprecio (cuando no odian abiertamente) la GPL. Es más, su plan para FreeBSD 10 es erradicar por completo cualquier línea de código GPL de la base del sistema. Por esta razón, no es sorprendente que no sientan un amor incondicional por ZFS, que está licenciado bajo la CDDL. Por muchas cualidades que tenga, se trata de un sistema de archivos no BSD.

Así que, lejos de adoptar ZFS como sistema de archivos definitivo, siguen mejorando su UFS. Y una de las mejoras más curiosas de 9.0 es una curiosa mezcla de softupdates + journaling.

Softupdates consiste en que toda escritura a disco se ordene previamente en memoria respecto a todas las pendientes, más las que vengan, de modo que siempre se mantenga la coherencia del sistema de archivos sin necesidad de fsck ni journaling. En teoría es una idea sencilla, en la práctica la implementación requiere una complejidad brutal. Se requiere introducir un sistema de mantenimiento de dependencias cuya complejidad no se puede abstraer tras una API, es esa clase de complejidad que se extiende como un vertido de petróleo a toda la implementación del sistema de archivos, requiriendo en cada operación lidiar manualmente con las clases de dependencia, sus estados, operaciones de "roll back" y "roll forward"...todo eso añadido a la complejidad del propio sistema de archivos, que no es poca. Si quieren, puede intentar leer este artículo de LWN sobre el tema, donde una mujer que trabajó en inventar ZFS reconoce su incapacidad para entenderlo por completo.

Y, tras lidiar con toda esta complejidad, resulta que softupdates no es capaz de acabar con todas las incoherencias que puedan ocurrir. Existen una serie de incoherencias benignas que no impiden el uso normal del sistema de archivos (bloques marcados como usados que en realidad están libres), pero requieren un fsck. El fsck se puede ejecutar "de fondo", sin necesidad de esperar a que termine para montar el sistema de archivos, pero el I/O y CPU necesarios para escanear todo el sistema de archivos no se los quita nadie.

Por eso no debe sorprender que al final mucha gente acabara pasando de este sistema y pidiera journaling. Como los BSDs son así, ni tan siquiera para añadir journaling se pusieron de acuerdo, así que FreeBSD añadió una cosa llamada "gjournal" (implementado a nivel de gestor de volúmenes, no del sistema de archivos - no me pregunten por qué) y NetBSD una cosa llamada WAPBL.

Pues bien, en FreeBSD 9.0 han decidido ir más allá. Se trata de un micro-journal que hace journaling de las pocas operaciones cuya coherencia softupdates no era capaz de garantizar. De ese modo, en pleno 2011, FreeBSD puede tener softupdates sin necesidad de fsck de fondo posterior, todo ello gracias a la implementación del mismo mecanismo que softupdates trataba de evitar. ¡Albricias! Todo esto para un sistema de archivos que no soporta ninguna de las características avanzadas de ZFS, y que no les quita de encima la necesidad de implementar un sistema de archivos de nueva generación con licencia BSD.

La próxima vez que vean un comentario BSDero hablando de lo chapuceros que son en Linux, acuérdense de esto.

Predicciones 2012

La última vez que me arriesgué a hacer predicciones fue en 2010. Que, por cierto, no fueron todas desencaminadas. A ver qué da de si el 2012:

· La Gente Normal (tm) empezará a usar masivamente tabletas como sustitutos de portátiles y netbooks. "Cuando éramos jóvenes utilizábamos ratones".

·Aunque Android avanzará, el iPad seguirá siendo líder en cuota de mercado de tabletas (para que no digan que no me arriesgo).

·Hablando de Apple, veremos por fin la iTV. No es una predicción muy original, todo el mundo la está haciendo. La "televisión inteligente" se convertirá en el objeto tecnológico de consumo por excelencia a final de año.

· A pesar de las quejas y de los competidores, Ubuntu seguirá progresando como distribución Linux para emigrantes de Windows.


·Una que robo a LWN: las guerras de patentes de software en el mercado de los smartphones empeorarán y se recrudecerán. Todas ellas dirigidas a Android, por descontado.


· Las cifras de ventas de Nokia -no catastróficas, pero tampoco suficientes para mantener a un gigante- obligarán a la compañía a hacer enésimas rondas de despidos, vender patentes, divisiones, la empresa entera...

· Windows Phone cumplirá sus expectativas, tendrá más éxito del que sus dueños le preveían, y de ese modo logrará consolidarse en un glorioso y merecido tercer puesto en cuota de mercado de sistemas operativos para smartphones.

· Windows 8 verá la luz, pero a nadie le importará gran cosa.


· Steve Ballmer dejará Microsoft.

. Mandriva conseguirá sobrevivir la quiebra.

· Firefox conseguirá frenar su deterioro. Las últimas versiones son buenas y no parece que vayan a dejar de pisar el acelerador.

· Google integrará Google+ en prácticamente todos los rincones de sus servicios.

· Youtube arreglará de una vez por todas el patético e intolerable fallo que supone el mostrar en la lista de sugerencias vídeos cuya valoración de los usuarios es clamorosamente negativa.

· Youtube se convertirá en alternativa seria a Netflix.

· Youtube + Chrome usará reproductor HTML5 por defecto.

· Y por último: Nacerá alguna distro Linux (no Android) orientada exclusivamente a dispositivos táctiles.

Las novedades de Linux 3.2

Ya se ha anunciado la disponibilidad de la versión 3.2 del kernel Linux. Novedades: Soporte para tamaños de bloque de Ext4 mayores que 4KB y hasta 1MB. Btrfs realiza el proceso de scrubbing más rápido, hace copias de seguridad automáticas de metadatos críticos y añade capacidad de inspeccionar manualmente el sistema de archivos. El gestor de procesos ha añadido soporte para poner límites máximos al tiempo de CPU que pueden usar los progresos. La respuesta del escritorio en presencia de fuertes escrituras de disco ha mejorad. TCP incluye un algoritmo que mejora la recuperación de las conexiones tras pérdidas de paquetes. La herramienta de análisis "perf top" ha añadido soporte para inspección en vivo de procesos y librerías y explorar ensamblador con código anotado. El Device Mapper soporta "thin provisioning" de espacio de almacenamiento. Y se ha añadido soporte para una nueva arquitectura, el Hexagon DSP de Qualcomm. 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.


· Ext4: Tamaños de bloque mayores de 4KB y hasta 1MB: El tamaño máximo de un bloque del sistema de archivos siempre ha sido de 4KB en sistemas x86. Pero la capacidad de almacenamiento de los discos modernos es enorme y sigue creciendo a gran velocidad, y a medida que crece la sobrecarga de tener que dividir discos tan grandes en unidades tan pequeñas aumenta. Los bloques pequeños benefician a los usuarios que tienen archivos pequeños, porque el espacio se utilizará con más eficiencia, pero las personas que manejan grandes archivos se beneficiarían de tamaños de bloque más grandes.

Ext4 soporta ahora tamaños de bloque de hasta 1MB, lo cual disminuye considerablemente el tiempo que se tarda en hacer asignaciones de bloques, y se mejora la fragmentación. Estos nuevos tamaños de bloque pueden configurarse en tiempo de creación del sistema de archivos, utilizando la opción -C de mkfs (requiere e2fsprogs 1.42). Esta característica no es compatible hacia atrás con kernels antiguos.


· Btrfs: scrubbing más veloz, copia de seguridad automática de metadatos críticos, mensajes de corrupción detallados, inspección manual de los metadatos:

 · Scrubbing más veloz: el proceso de scrubbing -comprobación de todos los checksums del sistema de archivos- es más veloz debido al uso de técnicas de "read-ahead". En un volumen de prueba, la utilización del ancho de banda del disco aumentó de 70% al 90%. En otro volumen, el tiempo para ejecutar una prueba de scrub pasó de 89 segundos a 43.

 · Copia de seguridad automática de metadatos críticos: Btrfs almacena en el superbloque del sistema de archivos las raíces de los árboles "B-Tree" de los últimos cuatro commits (debido al diseño COW, varias de esas raíces cambian en cada commit). Se ha añadido una opción de montaje "-o recovery" para permitir que el usuario utilice esas copias de seguridad cuando el sistema de archivos no pueda leer las raíces por algún problema.

 · Mensajes de corrupción detallados: Btrfs siempre ha tenido en sus estructuras internas "referencias inversas" que permiten hallar qué archivos o B-trees referencian a un bloque determinado, pero hasta ahora había que "caminar" esas referencias manualmente. En esta versión se ha añadido código, permitiendo como resultado la mejora de los mensajes de error de corrupción. Ahora, en lugar de decir que el bloque xxyyzz es erróneo, imprimirá esto:

  btrfs: checksum error at logical 5085110272 on dev /dev/sde, sector 2474832, root 5, inode 32583, offset 0, length 4096, links 1 (path: default/kernel-0/Makefile)
 · Inspección manual del sistema de archivos: Como parte de la característica anterior, se ha añadido código que permite la inspección manual del sistema de archivos desde espacio de usuario Para encontrar el archivo que pertenece al extent 5085110272, puedes ejecutar:

  btrfs inspect logical 5085110272 /mnt

  O, para encontrar el nombre de archivo perteneciente al inodo número 32583:

  btrfs inspect inode 32583 /mnt

 · Controlador de tiempo de CPU de procesos que permite poner límites máximos de CPU: El gestor de procesos divide la CPU disponible entre cada proceso si hay tiempo libre, porque se supone que todos los procesos desean tanto tiempo de CPU como sea posible. Pero en algunas compañías como Google esta asignación descontrolada de tiempo puede conducir a variaciones de utilización de CPU y latencia inaceptables.

El controlador de tiempo de CPU resuelve este problema permitiendo asignar un límite máximo de tiempo de CPU. El tiempo de CPU permitido para un grupo de procesos es especificado mediante una "cuota" y un "periodo". Durante cada "periodo" (en microsegundos), se permite a un grupo consumir la cantidad de microsegundos indicados en "cuota". Una vez superada la cuota, no se permite a los procesos que vuelvan a ejecutarse hasta el próximo periodo.

 · Provisionamiento fraccionario ("thin provisioning") y snapshots recursivos en el Device Mapper: Habitualmente, provisionar espacio de almacenamiento para múltiples usuarios puede ser ineficiente. Por ejemplo, si 10 usuarios necesitan 10 GB cada uno, necesitarás provisionar 100 GB de almacenamiento en total. Esos usuarios, sin embargo, probablemente no utilizarán todo ese espacio. Vamos a suponer que, de media, utilicen sólo el 50% de su espacio asignado: sólo utilizarán 50GB, dejando otros 50GB sin utilizar.

El "thin provisioning" o provisionamiento fraccionario permite asignar a todos los usuarios más espacio del que realmente hay. En el caso anterior, podrías comprar sólo 50 GB de almacenamiento, permitir a cada usuario tener 10 GB de almacenamiento máximo teórico y no tener problemas, porque los 50GB que comprastes son suficientes para atender las demandas reales. Y si los usuarios incrementan la demanda de espacio, puedes añadir más capacidad. Gracias al provisionamiento fraccionario, se puedes optimizar la inversión en almacenamiento y evitar sobre-provisionar.

Linux 3.2 añade soporte experimental para provisionamiento dinámico en la capa de Device Mapper. Los usuarios podrán crear un pool de almacenamiento y crear múltiples volúmenes provisionados fraccionadamente. Otra gran característica incluído en este "DM target" de provisionamiento fraccionario es el soporte para snapshots con recursión de profundidad arbitraria, y que evitan la degradación con la profundidad.

 · Mejora de la función de writeback de la VM: "writeback" es el proceso de escribir datos de la RAM al disco. Una parte crítica del proceso de "writeback" es decidir cuántos datos sin escribir puede mantener un proceso en la RAM. En este kernel, los algoritmos para tomar esa decisión han sido reescritos. Como resultado, los movimientos de brazo del disco duro y el uso de CPU se han reducido, los usuarios notarán un comportamiento más suave en cargas que utilizan write() en un loop, y también en NFS, JBOD y dd's concurrentes. La contención de bloqueos y el "cache bouncing" en cargas concurrentes ha mejorado.

· TCP Proportional Rate Reduction: TCP intenta alcanzar el máximo ancho de banda en una conexión incrementando el ratio de transferencia hasta que empieza a perder paquetes. Cuando un paquete se pierde, TCP enlentece la conexión y la aumenta poco a poco de nuevo.

Este sistema funciona bien, pero hay algunos casos en los que se pierden paquetes, se tarda demasiado tiempo en recobrar la máxima velocidad. Google ha desarrollado un algoritmo de recuperación mucho mejor, llamado "Proporcional Rate Reduction", que mejora la latencia y el tiempo de recuperación en esos casos.

· Mejora de la herramienta de análisis "perf top": La herramienta de análisis en vivo "perf top" ha sido reescrita y mejorado. Más allá de las mejoras visuales, también ha adquirido la capacidad de navegar mientas la captura de datos está ocurriendo, y puede hacer zoom a librerías y procesos particulares, así como ver, incluso, el ensamblador con anotaciones de código, todo ello en vivo.


· Cross Memory Attach: "Cross Memory Attach" añade dos llamadas al sistema -process_vm_readv, process_vm_writev-, que permiten leer/escribir de/a el espacio de dirección de otro proceso. La idea detrás de este mecanismo es facilitar la función de los programas MPI.

· Nueva arquitectura: Hexagon: El procesador Hexagon es un procesador DSP de propósito general diseñado para alto rendimiento y bajo consumo. Mezcla el soporte numérico, paralelismo y capacidades de un procesador DSP, con la arquitectura avanzada de los procesadores modernos.


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

¿Cuánto se invierte en Btrfs comparado con Ext4?

En este PDF está la respuesta, que compara el trabajo de todo un año, medido en Octubre (nota: la segunda columna son "desarrolladores con más de 10 commits"):

Y la respuesta es la que todo aficionado al software libre desearía oír: Se está invirtiendo más trabajo en Btrfs más que en cualquier otro sistema de archivos linuxero. Y es sorprendente comprobar que XFS tiene más actividad que Ext4 (ha tenido un resurgimiento últimamente).

Lo cual no es obstáculo para afirmar que Btrfs agradecería más apoyo, de esos "11 desarrolladores con más de 10 commits en un año" (una medida bastante generosa) seguramente no trabajen a tiempo completo en Btrfs ni la mitad, y no es que falte trabajo por hacer. Pero en ese aspecto, en Linux las cosas siempre han sido así.