30 de diciembre de 2008

Sobre como ATI afianza el liderazgo en Linux con soporte 3D para tarjetas ATI R600/700

Phoronix cuenta que AMD publicará en un mes documentación para hacer funcionar la "parte 3D" sus tarjetas con chips R600/700 en Linux. Pero además, hoy han publicado el correspondiente driver DRM. Está claro que el apoyo de AMD/ATI a Linux no era cosa de unos días, ni de publicidad, sino un apoyo real que día a día se materializa en más y más código real que resuelve los problemas de la gente...

Esto situa cada vez más a AMD/ATI en una posición privilegiada en el mundo Linux. Antes de que AMD/ATI empezara con esto, solo Intel tomaba una determinación de soporte de Linux igual de firme. Pero los gráficos integrados de Intel solo tienen potencia para mover un escritorio compiz, ver DVDs o jugar a juegos simples: más que suficiente para la mayoría de la humanidad, razón por la cual los chips gráficos de Intel son los que más vendidos y los que tienen mayor cuota de mercado, pero corto de potencia para los usuarios con más conocimientos informáticos y vicio jugón. Para bien o para mal los usuarios Linuxeros suelen ser de esos, y prefieren contravenir la tendencia general de la humanidad eligiendo potentes gráficas ATI o Nvidia.

Hasta ahora, muchos de ellos escogían Nvidia por la mejor calidad de sus drivers frente a AMD/ATI: Puestos a escoger un malvado driver propietario, mejor uno bueno que uno malo. En breve toda esa gente empezará a escoger gráficas ATI por razones obvias: buena potencia -además, tengo entendido que AMD/ATI ha hecho una jugada maestra y sus las últimas gráficas son mejores que las correspondientes de Nvidia- y drivers libres y capaces. ¿Teniendo esto, quien querría una Nvidia después de esto?

Un servidor, sin ir más lejos, a la hora de renovar su placa base, escogió una con gráficos Intel integrados. En aquel tiempo ya se oía de la aproximación de AMD/ATI al software libre, pero no había nada sólido, así que tiré a lo seguro: Jamás juego, y a pesar de poder ni tan siquiera uso ya compiz a diario. Aun así, compré esta placa base pensando en que algún día, cuando lo de AMD/ATI progresara, desactivaría los gráficos integrados de Intel y compraría una ATI bien soportada por drivers libres. Parece que ese día está a la vuelta de la esquina.

Al menos que Intel dé la sorpresa con Larrabe, claro está....

25 de diciembre de 2008

Lo que traerá Linux 2.6.28, parte II

Linus se me ha adelantado, pero aquí está: La segunda parte del resumen de las principales novedades del aún no publicado Linux 2.6.28 (lista completa en ingles, aqui). La primera parte fue dedicada a Ext4, la principal novedad de esta versión. He aquí un resumen del resto:

  • GEM, el gestor de memoria gráfica: En la última década el hardware gráfico ha evolucionado a un ritmo asombroso. Las GPUs de hoy tienen una inmensa capacidad de cálculo que tradicionalmente (utilizar esta palabra al hablar de la evolución del mundo informático tiene cierta ironía) solo ha sido aprovechada por aplicaciones especializadas que hacen uso de opengl/directx, como juegos y el diseño 3D; los escritorios 2D que todo el mundo conoce y utiliza han seguido usando este hardware moderno del mismo modo que usaban el antiguo, el que inició la "revolución del escritorio" en los 80-90. Es decir, con métodos ineficientes. Hay mucha potencia de cálculo en las GPUs que no se utiliza al menos que uses un juego. Por otra parte, la arquitectura del subsistema gráfico de Linux está lejos de considerarse perfecta, incluso desde el punto de vista de la arquitectura gráfica del hardware antiguo. Para empezar, hay varios drivers luchando para conseguir acceso al mismo recurso (la tarjeta gráfica): La consola basada en el framebuffer, la consola VGA sin framebuffer, el driver DRM que está dentro del kernel, el driver 2D de X.org que funciona en espacio de usuario...esta situación provoca toda clase de problemas y proporciona un rendimiento subóptimo.

    Se ha trabajado mucho en los últimos años para modernizar la arquitectura gráfica de Linux de manera que esté bien diseñada y que sea capaz de utilizar toda la potencia de las GPUs modernas y futuras. En 2.6.28, Linux incluye una de las partes más importantes de esa arquitectura: Un gestor de memoria para la memoria de la GPU, llamado GEM ("Graphic Execution Manager"). El propósito es disponer de un gestor central para gestionar "objetos buffer", su localización, su cacheado, su mapeado y su sincronización. En los cimientos de GEM se están construyendo muchas otras mejoras : Kernel Modesetting, DRI2, UXA (una implementación de EXA basada en GEM).

    Todo este código ha sido retrasado durante bastante tiempo, debido a que había un gestor de memoria anteriormente, llamado TTM, que casi fue incluido en Linux 2.6.24, hasta que de repente la gente de Intel apareció con las primeras versiones de GEM. Se decidió que éste era mejor que TTM, y se consideró necesario retrasar la inclusión de TTM y la renovación de toda la arquitectura gráfica para estabilizar GEM. Esta es la razón por la que en esta versión GEM solo funciona con el driver i915, y el soporte de X.org solo está implementado en la versión 2.5.0 del driver Intel. Existen parches preliminares que ofrecen soporte para otros drivers que serán incluidos en futuras versiones.

  • Soporte de "Ultra Wide Band" (WB), USB inalámbrico y UWB-IP: UWB es una un protocolo de comunicación punto-a-punto de bajo consumo y alta velocidad, que utiliza un amplio espectro (3.1-10.6 GHz). Está optimizado para comunicaciones dentro den el espacio de una habitación (480Mbps a 2 metros, 110Mbps a 10). Sirve como capa de transporte a otros protocolos, como el USB inalámbrico, el protocolo de enlace WiMedia (Ethernet/IP sobre UWB) y, en el futuro, Bluetooth y 1394. Linux 2.6.28 añade el código necesario para implementar una pils UWB, así como drivers para los dispositivos más comunes

  • Escalabilidad de la gestión de memoria:
    • Mejoras al algoritmo de reemplazo de páginas: Los sistemas con mucha memoria tienen muchas (millones) de páginas. Cuando el algoritmo de reemplazo tiene que buscar una página candidata a ser enviada al swap, tiene que buscar entre todas las páginas, y en los grandes sistemas esta puede ser una tarea muy costosa. En 2.6.28, las páginas respaldadas por archivos (páginas correspondientes al cache de un archivo y que una vez descartadas de la memoria pueden volver a ser leidas de ese archivo) y las páginas anónimas (las que no corresponden a ningun archivo -por ejemplo las obtenidas a través de malloc()- y que, por lo tanto, tienen que ser escritas en el swap antes de ser descartadas de la memoria) son clasificadas en dos listas diferentes, en lugar de una sola, como sucedía anteriormente. Los algoritmos encargados de seleccionar una página pueden por lo tanto mirar en una de esas listas sin tener que mirar la otra. Tambien existen páginas que no pueden ser descartadas de la memoria en absoluto, por ejemplo, las que están mlock()eadas, o las pertenecientes a un sistema de archivos ramfs. Esas páginas se ubican en una tercera lista que no será consultada por ningún algoritmo de selección de páginas, por la simple razón de que no puede descartarse ninguna de ellas.

    • Reescritura de la capa vmap: En 2.6.28, se ha reescrito el asignador vmap utilizando rbtrees y flusheado "vago" de la TBL, para proporcionar una implementación rapida y escalable. Algunas comparativas que ejercitan este asignador se han acelerado por 20 o más.

  • Congelador de procesos de containers: El congelador de procesos de containers es un subsistema implementado como cgroup que utiliza el congelador de procesos de la suspensión por software para congelar y reiniciar grupos de procesos arbitrariamente escogidos por el usuario. Es inmediatamente útil para ir encolando scripts de mantenimiento. Será tambien útil en el futuro para implementar reinicio y checkpointing de containers.

  • Traceador de arranque: El proposito de este traceador es ayudar a los desarrolladores a optimizar los tiempos de inicio: guarda los tiempos de las initcalls. Su propósito es ser parseado por el script hallado en scripts/bootgraph.pl para crear gráficos que muestren las ineficiencias del proceso de arranque, dando una representación visual de los retrasos que hay entre las initicalls. Los usuarios tendrán que activar CONFIG_BOOT_TRACER, y arrancar el kernel con los parámetros "initcall_debug" y "printk.time=1" (este último si no se tiene activada las marcas de tiempo en cada mensaje de dmesg), y ejecutar "dmesg | perl scripts/bootgraph.pl > output.svg" para generar los gráficos.

  • Protección del disco contra golpes: El estándar ATA/ATAPI-7 especifica los detalles sobre el comando IDLE IMMEDIATE. Enviar este comando debería hacer que la unidad se pusiera en modo de reposo y descargara los cabezales del disco. Esta característica se utiliza en los portátiles modernos junto a acelerómetros y un software apropiado para implementar una herramienta de protección del disco. La idea es detener todas las operaciones de I/O del disco y aparcar los cabezales cuando se puedan anticipar situaciones criticas.

    Para cada dispositivo ATA, Linux 2.6.28 añade el archivo /sys/block/*/device/unload_heads. Escribiendo un valor entero a este archivo apartará los cabezales del respectivo dispositivo de los platos del disco durante el número especificado de milisegundos. Cuando el temporizador expira, las operaciones continuan normalmente. El máximo valor aceptado son 30.000 milisegundos (30 segundos). Sin embargo, existen algunos discos duros que solamente cumplen con una versión anterior del estándar ATA, pero que soportan esta característica de todos modos. Desgraciadamente, no hay una manera segura que Linux pueda utilizar para detectar esos dispositivos, asi que para ellos no se podrá escribir en su archivo unload_heads. Si sabes que tu disco duro verdaderamente lo soporta (por ejemplo, porque quien te vendió el portátil te lo ha dicho), entonces puedes ordenar al kernel que lo active escribiendo el valor especial -1 al archivo. Lee esta página para más información de como Linux soporta la protección de discos duros de los Thinkpads IBM/Lenovo.

  • Protocolo de red Phonet: El protocolo "Phone Network" (PhoNet) es un protocolo de comunicación orientado a paquetes que ha sido desarrollado por Nokia para ser utilizado en los módems de sus móviles tanto para IPC como RPC. Con la familia de sockets Phonet, los procesos pueden enviar y recibir y enviar mensajes de/hacia el modem, o de cualquier otro dispositivo externo conectado al modem; el modem se ocupa del ruteo. Los paquetes Phonet pueden ser enviados a través de diferentes conexiones hardware: USB con la interfaz CDC Phonet, infrarrojos, Bluetooth, un puert serie.... Este protocolo es un requisito para que Maemo pueda utilizar la conectividad de móviles; tambien puede usarse para controlar móviles Nokia.

  • Redes: Proxying transparente, nuevos drivers, DSA...
    • Soporte de la Arquitectura Distribuida de Switchs (DSA): DSA es un protocolo para gestionar los chips de los switchs. Los switchs que este driver soporta son los que se pueden encontrar embebidos típicamente en routers y puntos de acceso.

    • Soporte de proxying transparente: Esta característica (perdida hace 5 años) permite el proxying transparente, es decir, soporte para gestionar sockets IPv4 TCP y UDP no locales. Añade un target de iptables "TPROXY", que es algo parecido a "REDIRECT". Solo puede ser utilizado en la tabla "mangle" y es útil para redireccionar tráfico a un proxy transparente. No depende de NAT, a diferencia de REDIRECT.

    • Nuevos drivers de red: Esta version añade unos cuantos drivers nuevos: atl2, SMSC LAN9500 USB2.0 10/100, enic: Cisco 10G Ethernet, qlge: Qlogic 10Gb Ethernet, jme: JMicron Gigabit Ethernet

  • Tracepoint: Los tracepoints son otro mecanismo para insertar puntos estáticos de trazado, que es utilizado por herramientas como LTT (Linux Trace Toolkit).

  • Drivers -staging: Dentro del kernel Linux existe una controversia entre la gente que piensa que los drivers nuevos deberían ser incluidos lo antes posible en el kernel, siendo aun de mala debido a su corta edad; y la gente que piensa que solo deberían incluise drivers con ciertos niveles de alta calidad. Para solucionarlo, se ha creado un repositorio llamado "-staging", en el que se incluyen varios drivers de los que son muy nuevos y suelen encontrarse en sus propias páginas web y no en el repositorio principal de Linux. Estos drivers se ubican en drivers/staging y son mantenidos ahí mientras no tengan la calidad necesaria. En el log completo en inglés se puede leer la lista de drivers -staging incluidos en esta versión.

  • FIEMAP: Cuando una aplicación quiere saber como se ha almacenado un archivo en el disco (por ejemplo, un programa de copia de seguridad que quiere saber si un archivo es del tipo "sparse", para no tener que copiarle entero), utiliza la ioctl fibmap. Pero esta ioctl es subóptima - solo puede pedir información sobre un solo bloque cada vez, lo cual es demasiado ineficiente en el caso de grandes archivos. La ioctl FIEMAP sin embargo devuelve una lista de extents, permitiendo devolver la información de un archivo en una sola llamada

22 de diciembre de 2008

Ext4 (lo que traerá Linux 2.6.28 parte I)

Parte de la documentación de Linux 2.6.28 en el fascista y opresor idioma ejpañol (versión en inglés de este documento).

Ext4 es la evolución del sistema de archivos más utilizado en el mundo Linux, Ext3. En muchos sentidos Ext4 es una mejora más profunda de Ext3 que la que Ext3 fue de Ext2. Ext3 consistió básicamente en añadir journaling, pero Ext4 modifica ciertas estructuras críticas del sistema de archivos, como las destinadas a almacenar los datos de los archivos. El resultado es un sistema de archivos con un diseño mejorado, mayor rendimiento y fiabilidad. Las principales mejoras que ofrece son:

  • Compatibilidad: Cualquier sistema de archivos Ext3 existente puede migrarse a Ext4 con un sencillo procedimiento de dos comandos a ejecutar en modo de solo-lectura (procedimiento descrito más adelante). Es decir, que puedes mejorar el rendimiento, límites de almacenamiento y características de un sistema de archivos sin necesidad de reformatear y/o reinstalar tu SO y entorno de software. Si necesitas las ventajas de Ext4 en un entorno de producción, puedes actualizar el sistema de archivos. El procedimiento es sencillo y no pone en riesgo los datos (eso si, se recomienda hacer copia de seguridad de los datos críticos, incluso si no estás actualizandote el sistema de archivos :). Ext4 solamente utilizará sus nuevas estructuras en los nuevos datos que se escriban, los datos antiguos podrán continuar siendo leidos y modificados cuando sea preciso. Esto significa, por supuesto, que una vez que se convierte el sistema de archivos a Ext4, no se puede regresar a Ext3 (aunque hay una posibilidad de montar un sistema de archivos Ext3 con Ext4 de modo que no se utilize el nuevo formato de disco, y así poder volver a montarlo con Ext3, pero así se pierden muchas de las ventajas de Ext4)

  • Mayores tamaños del sistema de archivos y de los archivos: Ext3 soporta 16 TB como máximo tamaño del sistema de archivos, y 2 TB de tamaño máximo de cada archivo. Ext4 añade direccionamiento de bloques de 48 bits, y tendrá 1 EB de tamaño máximo de sistema de archivos y 16TB de tamaño máximo de archivo. 1EB = 1.048.576 TB (1EB = 1024 PB, 1 PB = 1024 TB, 1 TB = 1024 GB). ¿Por qué 48 bits, y no 64? Hay algunas limitaciones que necesitan ser solucionadas antes de que Ext4 sea capaz de soportar 64 bits, y esas limitaciones no han sido tratadas en Ext4. Las estructuras de datos de Ext4 han sido diseñadas teniendo esto en mente, de modo que una futura actualización a Ext4 implementará soporte completo de 64 bits. 1EB será suficiente (en serio :) hasta que llegue ese momento. (Nota: el código para crear sistemas de archivo mayores de 16 TB no está presente en ninguna versión estable de e2fsprogs)

  • Escalabilidad de subdirectorios: El número máximo de subdirectorios que puede contener un solo directorio en Ext3 es 32.000. Ext4 rompe ese límite y permite un número ilimitado de subdirectorios.

  • Extents: Los sistemas de archivo tradicionales derivados de Unix, como Ext3, utilizan un sistema de mapeo de bloques indirecto para llevar cuenta de cada uno de los bloques correspondientes a los datos de un archivo. Este sistema es ineficiente para los archivos grandes, especialmente a la hora de borrarlos o truncarlos, porque el mapeado mantiene una entrada para cada bloque, y los archivos grandes tienen muchos bloques -> mapeados gigantescos cuya manipulación es lenta. Los sistemas de archivo modernos utilizan un sistema distinto llamado "extents". Un extent es básicamente un montón de bloques físicamente contiguis. Básicamente dice: "Los datos están en los próximos n bloques". Por ejemplo, a un archivo de 100 MB puede asignarsele un solo extent de ese tamaño, en vez de tener que crear un mapeado indirecto para 25.600 bloques (4KB por bloque). Los archivos gigantescos son divididos en varios extents. Los extents mejoran el rendimiento y tambien ayudan a reducir la fragmentación, ya que animan a a utilizar rangos continuos en el disco.

  • Asignación multibloque: Cuando Ext3 tiene que escribir nuevos datos al disco, hay un asignador de bloques que decide qué bloques libres serán utilizados para escribir esos datos. Pero el asignador de bloques de Ext3 solo puede asignar un bloque (4KB) de una vez. Esto significa que si el sistema necesita escribir los 100 MB de datos mencionados anteriormente, tendrá que llamar al asignador de bloques 25600 (¡y solamente son 100 MB!). No solo esto es muy ineficiente, no permite al asignador optimizar la política de asignación porque no puede saber cuantos datos van a asignarse en total, solo sabe lo de un bloque. Ext4 utiliza un "asignador multibloque" (mballoc), que puede asignas muchos bloques en una sola llamada, en lugar de un bloque por llamada, evitando de ese modo sobrecarga. Esto mejora el rendimiento, y es especialmente útil con asignación diferida y extents. Esta característica no afecta el formato del disco. Tambien hay que tomar nota de que el asignador de bloques/inodos de Ext4 tiene muchas otras mejoras, descritas en detalle en este documento.

  • Asignación diferida: La asignación diferida, en inglés delayed allocation, es una mejora de rendimiento (no cambia el formato del disco) que se encuentra en sistemas de archivos modernos como XFS, ZFS, btrfs or Reiser 4; no es una técnica muy expandida por haber sido considerado hasta hace poco como "peligrosa", y que consiste en retrasar la asignación de bloques lo más posible, contrariamente a lo que los sistemas de archivo tradicionales (como Ext3, reiser3, etc) hacen: asignar los bloques tan pronto como es posible. Por ejemplo, si un proceso escribe con write() algo, el sistema de archivos asignará inmediatamente los bloques en los que se colocarán los datos - incluso si los datos no se están escribiendo al disco en ese mismo momento y se van a mantener en el cache algún tiempo. Esta aproximación tiene desventajas. Por ejemplo, cuando un proceso está escribiendo continuamente datos a un archivo que va creciendo, write()s sucesivos asignarán bloques para los datos, pero el sistema de archivos no puede saber si el archivo va a continuar creciendo. Sin embargo, la asignación diferida no asigna los bloques inmediatamente cuando el proceso usa write()s; en vez de eso, difiere la asignación mientras los datos del archivo se mantengan en el cache, hasta que se escriban definitivamente en el disco. Esta aproximación da la oportunidad al asignador de bloques de optimizar la asignación en situaciones en las que el antiguo sistema no podía. La asignación diferida encaja muy bien con las dos anteriormente mencionadas características, extents y asignación multibloque, porque en muchos tipos de carga, cuando el archivo se escribe finalmente al disco, puede asignarse en extents cuya asignación de bloques se ha llevado a cabo con el sistema de asignación multibloque. El rendimiento mejora, y la fragmentación se disminuye en ciertos tipos de carga.

  • Fsck rápido: Hacer un fsck es una operación muy lenta, especialmente el primer paso: comprobar todos los inodos del sistema de archivos. En Ext4, al final de cada tabla de grupo de inodos se almacena una lista de inodos no utilizados (junto a un checksum, por seguridad), de modo que el fsck no los comprobará. El resultado es que el tiempo de fsck mejora de 2 a 20 veces, dependiendo del número de inodos utilizados. Hay que notar es fsck, y no Ext4, quien construye la lista de inodos no utilizados. Esto significa que tendrás que pasar un fsck para que se construya la lista de inodos no utilizados, y entonces el próximo fsck será el que sea más rápido (necesitas pasar un fsck para convertir un sistema de archivos Ext3 a Ext4 de todos modos). Hay tambien una característica que toma parte en este aceleramiento del fsck - "flexible block groups" - que tambien acelera las operaciones normales del sistema de archivos.

  • Checksumming del Journal: El journal es la parte más utilizada del disco, lo cual hace que los bloques que forman parte de él sean más susceptibles a sufrir un fallo de hardware. Y tratar de recuperar un log de un journal corrupto puede inducir a una corrupción masiva. Ext4 hace un checksum del journal para saber si los bloques del journal están fallando o están corruptos. Pero el checksumming del journal tiene un bonus: permite convertir el sistema de dos fases de Ext3 a una sola fase, acelerando las operaciones del sistema de archivos hasta en un 20% en algunos casos - asi que en este caso se gana fiabilidad y rendimiento al mismo tiempo. (Nota: La parte de esta característica que mejora el rendimiento, el logging asíncrono, está desactivado por defecto y será activado en el futuro)

  • Defragmentación en vivo: (Esta característica no está disponible en 2.6.28, pero probablemente lo estará en la próxima versión). Aunque la asignación diferida, los extents y la asignación multibloque ayudan a reducir la fragmentación, con el uso los sistemas de archivos pueden fragmentarse. Por ejemplo: Escribes tres archivos en un mismo directorio y contiguamente en el disco. Algún día necesitas actualizar el archivo del medio, pero el archivo actualizado es un poco más grande, asi que no hay suficiente espacio para él. No queda otra opción que fragmentar el exceso de datos a otro lugar del disco, que causara movimiento de brazo extra en el disco y por tanto pérdida de rendimiento, o tambien puedes asignar para el archivo actualizado espacio contíguo en otro lugar lejano a los otros dos archivos, lo cual causará movimiento de brazo si una aplicación necesita leer todos los archivos de un directorio (por ejemplo, un gestor de archivos creando miniaturas de un directorio lleno de imágenes). Además, el sistema de archivos solo puede ocuparse de ciertos tipos de fragmentación, no puede saber, por ejemplo, que debe mantener todos los archivos relacionados con la carga del SO juntos, porque no sabe qué archivos están relacionados con la carga del SO. Para solventar este problema, Ext4 soporta defragmentación en vivo, y hay una herramienta llamada e4defrag que puede defragmentar archivos individuales o todo el sistema de archivos.

  • Características relacionadas con los inodos: inodos más grandes, marcas de tiempo con granularidad de nanosegundos, atributos extendidos rápidos, reserva de inodos...

    • Mayores inodos: Ext3 soporta la configurabilidad de los tamaños de inodo (mediante el parámetro -I de mkfs), pero el tamaño de inodo por defecto es de 128 bytes. Ext4 por defecto tendrá 256. Este aumento es necesario para hacer espacio a varios campos extra (como la granularidad de nanosegundos o el versionamiento de inodos), y el tamaño restante del inodo será utilizado para almacenar atributos extendidos que sean lo suficientemente pequeños como para caber en ese espacio. Esto hará que el acceso a esos atributos sea mucho más veloz, lo cual aumenta entre 2 y 7 veces el rendimiento de las aplicaciones que hacen uso de estos atributos extendidos apodados "rápidos".

    • Reserva de inodos: La reserva de inodos consiste en reservar varios inodos para futuros archivos cuando se crea un directorio, confiando que serán utilizados en el futuro. Esto mejora el rendimiento, porque cuando los nuevos archivos sean creados en ese directorio podrán usar esos inodos que habían sido reservados. Por tanto, se mejora el rendimiento de la creación y eliminación de archivos.

    • Marcas de tiempo con granularidad de nanosegundos: Esto significa que los campos como mtime (modified time) o atime (access time) podrán usar una resolución de nanosegundos, en vez de la que hace uso Ext3, que tan solo alcanza una granularidad a nivel de segundo.

  • Preasignación persistente: Esta característica (disponible en Ext3 en las últimas versiones del kernel, y emulada la por glibc de no estar disponible) permite a las aplicaciones preasignar espacio de disco: El sistema de archivos asigna el espacio libre y los bloques necesarios, pero no hay ningún dato en ellos hasta que la aplicación verdaderamente se decida a escribirlos en el futuro. Esto es lo que las aplicaciones P2P hacen cuando preasignan espacio para descargas que tardarán horas o días en completarse, pero implementado con más eficiencia por el sistema de archivos y con una API genérica. Tiene muchos usos: en primer lugar, para evitar que las aplicaciones (como los P2P) lo hagan ellas mismas ineficientemente llenando un archivo de ceros. Segundo, para mejorar la fragmentación, ya que los bloques se asignarán de una sola vez para todo el archivo lo más contiguamente posible. Tercero, para asegurarse de que las aplicaciones tienen el espacio que ellas creen que van a necesitar, lo cual es importante para las aplicaciones tipo RT, ya que sin preasignación el sistema de archivos podría llenarse en la mitad de una operación importante. Esta característica está disponible mediante la interfaz de glibc posix_fallocate().

  • Barreras activadas por defecto: Esta opción mejora la integridad del sistema de archivos a costa de algo de rendimiento (se puede desactivar con "mount -o barrier=0", recomendado si estás haciendo benchmarks). De este artículo de LWN: "Antes de escribir el registro de commit [en el journaling], el código del sistema de archivos debe estar totalmente seguro de que todos los datos de las transaciones ha llegado al disco. Escribir los datos al disco en orden no es suficiente; los discos hoy en día tienen grandes caches y reordenarán las operaciones para mejorar el rendimiento. Asi que el sistema de archivos debe ordenar explicitamente al disco que escriba todos los datos del journaling antes de escribir los datos del registro de commit; si el registro de commit se escribe antes, el journal podría corromperse. El subsistema de E/S del kernel facilita esta tarea a travñes del uso de barreras; en esencia, una barrera prohibe la escritura de cualquier bloque tras la barrera, hasta que todos los bloques que se hayan escrito antes de la barrera estén realmente escritos en el disco. Utilizando barreras, los sistemas de archivos pueden estar verdaderamente seguros de que su estructura se mantiene siempre consistente en el disco"


Cómo usar Ext4:

Esta es la primera versión estable de Ext4, asi que aunque todo el desarrollo y lanzamiento final de este sistema de archivos se ha enlentecido y retrasado mucho para garantizar el mismo nivel de estabilidad que podría esperarse de las actuales implementaciones de Ext3, no dejan de aplicarse las mismas reglas que se aplican a todo software ".0".

Algo muy importante que hay que tener en cuenta es que NO hay soporte de Grub para Ext4. Bueno, eso no es del todo cierto: Hay soporte, pero no en las versiones utilizadas por las distros estables. Hay soporte en la rama de desarrollo de GRUB2, pero solo desde este commit. Hay paquetes de grub2 disponibles en Ubuntu y distros derivadas de Debian bajo el nombre "grub-pc". En la rama estable 0.9x, no hay soporte oficial, pero hay un proyecto de Google SoC que lo desarrolló, y Google encuentra parches. Asi que escoje. Las próximas distros basadas en Linux 2.6.28 probablemente tengan el soporte de un modo u otro. La opción segura es dejar tu directorio /boot en una partición Ext3.

Tambien necesitas una version de e2fsprogs actualizada, se recomienda la última versión estable, 1.41.3.

Migrar a Ext4 es muy sencillo. Hay tres métodos diferentes:

  • Creando un sistema de archivos desde cero: La opción más fácil, recomendada para las nuevas instalaciones. Simplemente actualiza el paquete e2fsprogs a Ext4, y crea el sistema de archivos normalmente.

  • Migrar un sistema de archivos Ext3 existente a Ext4: Tienes que utilizar la herramienta tune2fs en el sistema de archivos deseado, y ese sistema de archivos DEBE estar desmontado. Ejecuta:

    # tune2fs -O extents,uninit_bg,dir_index /dev/tusistemadearchivos

    Despues de ejecutar esto, DEBES pasarle un fsck. Si no lo haces, Ext4 NO MONTARÁ el sistema de archivos. Este fsck es necesario para devolver el sistema de archivos a un estado consistente. Te dirá que se han encontrado "checksum errors in the group descriptors". Es normal, eso es exactamente lo que tiene que reconstruirse para poder ser montado con Ext4, asi que no te sorprendas al verlos. Dado que para a preguntarte cada vez que encuentra uno de esos fallos, siempre responde que SI. Si no quieres que te pregunte, pásale el parámetro "-p" a fsck, significa "reparación automática":

    # fsck -pf /dev/tusistemadearchivos

    Hay otra cosa que debe mencionarse. Todos los archivos existentes continuarán utilizando el formato antiguo de mapeo indirecto para mapear todos los bloques de los datos. La herramienta de defragmentación en vivo permitirá migrar cada uno de esos archivos al formato de extents (utilizando una ioctl que ordena al sistema de archivos que reescriba el archivo en el formato de extents; puede utilizarse con seguridad mientras se usa el sistema de archivos con normalidad)

  • Montar un sistema de archivos Ext3 con Ext4, sin utilizar, de entre las nuevas características de Ext4, las que cambian el formato del disco. Podrás volver a montar el sistema de archivos con Ext3 de nuevo: Puedes montar un sistema de archivos existente con "mount -t ext4 /dev/tusistemadearchivos /mnt". Hacer esto sin haber hecho el proceso de conversión descrito en el punto de arriba forzará a Ext4 a no utilizar las características nuevas que utilizan el nuevo formato, solamente se utilizarán las características que no lo cambian, como mballoc o la asignación diferida. Se podrá, de este modo, volver a montar el sistema de archivos de nuevo como Ext3. Pero obviamente así te pierdes muchas de las ventajas de Ext4...

18 de diciembre de 2008

Si eres legal, COMPARTE

Como co-propietario de propiedad intelectual musical disponible a la descarga en redes P2P (cuyo nombre no pienso revelar, asi que no pregunten), me uno a la campaña: Si eres legal, comparte.

No pido sin embargo la dimisión del ministro: tan solo pido que se retracte de las campañas "antipiratería" y de futuras leyes que intenten penalizar el P2P, y que anule el canon de la SGAE (no necesita prohibirlo por la simple razón de que no es legal). No es mucho pedir, me parece. Si me permiten citar a Rosa Díez: tan solo pido que aplique la ley, no acepto demagogia.

17 de diciembre de 2008

Motorola se pasa a Android

...definitivamente. Incluso afirman que van a parar el desarrollo en 2009 para adaptar toda su línea de productos a Android...es decir, se cambian de forma total y absolutamente radical.

He de confesar que aunque en un principio Android me pareció una cosa interesante, con el tiempo (cuando Google cerró el desarrollo al público temporalmente, y despues de ver ciertas chapucerías como la de reiniciarse el móvil tecleando cuando escribias "reboot" con el teclado) me pareció que no tenía muchas posibilidades reales, pero el tiempo está demostrando que va pisando fuerte...

11 de diciembre de 2008

Exijamos la gratuidad de licencias en el software de la educación pública

Parece ser que una profesora estadounidense se ha puesto como un basilisco debido al proselitismo linuxero de uno de sus alumnos. El chaval enseñó Linux en su portátil y regaló CDs de muestra a sus compañeros, y la profesora, que parece tener una extraña fobia Linuxera, se los ha requisado y ha enviado un correo de protesta al creador de la distro en cuestión, HeliOS. Razonando que "ningún software es libre y es dañino que esa falsedad se extienda", y que vivimos en un mundo Windows, y no se cuantas tonterías más....

Al margen de la estupidez de la profesora -que "curiosamente" pertenece a un sindicato en el que Microsoft ha hecho su propio proselitismo monetario-, nunca ha de desaprovecharse la oportunidad de denunciar la importantísima colaboración de los colegios públicos en el mantenimiento de Windows como SO monopolístico.

El problema está en las clases de informática, que se suelen hacer con productos de Microsoft. ¿Cuantos millones se gastan los Gobiernos anualmente en formar a los estudiantes desde la más tierna edad en el uso de estos productos? O dicho de otra manera: ¿Cuantos millones se ahorra Microsoft con este sistema de formación masiva pagada por los contribuyentes? Luego se dice que todo el mundo sabe usar Windows, pero lo cierto es que aunque no sepan, se lo enseñan en la escuela pública...

Pero no acaba todo ahí. El estado TAMBIEN se gasta dinero en licencias de software para los equipos de enseñanza. Es decir, que el estado se gasta millones en licencias de productos Microsoft....para luego encima formar gratuitamente a nuestros niños en el uso de esos productos. Es un negocio por partida doble, muy lucrativo para Microsoft y con cargo a los bolsillos del contribuyente.

Y no me vengan con que es que Microsoft regala muchas licencias a los colegios y a las universidades. Es cierto: Microsoft hace ofertas y regalos especiales al sistema educativo. Pero 1) suele hacerlo como parte de negociaciones multimillonarias con el organismo político de turno en los que sale ganando de otro modo 2) no regala TODO el software (a menudo tan solo hacen descuentos)

Según entiendo yo las cosas es lo mínimo que debería hacer, regalar. Ya que la escuela pública va a formar con dinero público a los niños en el uso de esos productos, lo mínimo que se debería exigir desde el gobierno es que la empresa que va a salir beneficiada por esa formación regale todas las licencias de software. Todas, y si no están dispuestos, se da oportunidad a otra empresa que si que lo esté. Es un trato justo: El sistema educativo enseña a los alumnos a utilizar las nuevas tecnologías, y la empresa gana usuarios. De hecho la empresa sale favorecida, deberían aceptarlo sin quejas.

Por eso, me parece que es un noble fin exigir a la Administración -sea del partido que sea- que en la escuela pública el software escogido para la enseñanza informática -y tengan en cuenta que no he mencionado para nada en este razonamiento al software libre- se haga así por ley: Prohibido enseñar software que exija a las escuelas pago de licencias. Y por eso, creo que más de una persona comparte conmigo este bonito punto que tan bien encajaría en un programa electoral:

EXIJAMOS LA GRATUIDAD DE LAS LICENCIAS DE SOFTWARE EN LA EDUCACIÓN PÚBLICA (*).

(*: No tengo ningún odio particular contra la educación privada, pero la educación privada es asunto de quien la contrata y debe buscarse la vida por su cuenta)

4 de diciembre de 2008

Python 3.0

Acaba de anunciarse la publicación de Python 3.0. Una gran noticia. Además de por el magnífico lenguaje, la gente de python merece un aplauso por como han afrontado la enorme dificultad que supone sacar una nueva versión incompatible con la anterior y que no va a funcionar con la enorme masa de código python ya existente: En python 2.6 añadieron una opción que advertía a los programadores de las partes del código que no iban a funcionar en esta nueva versión, permitieron usar la funcionalidad de la futura versión 3.0 mediante "from __future__ import...", han escrito un programa que intenta (en la medida de lo posible, supongo) parchear código 2.x para que funcione en 3.0...lo han organizado todo perfectamente, minimizando al máximo el coñazo de tener que portar todo el código python disponible en el mundo a la nueva versión.

Mientras tanto, en perl empiezan a preocuparse seriamente sobre la viabilidad futura del lenguaje. No me extraña en absoluto: comparen el circo en el que se ha convertido Perl 6 con la magnífica estrategia y prontitud de Python 3.0...