En la trilogía que hice sobre tiendas de aplicaciones, un servidor predijo (con acierto: permítanme regodearme por una vez en uno) la futura extensión de la App Store de Apple a los Macs. Tampoco era difícil de adivinar: Los linuxeros sabíamos que eso de descargarse aplicaciones de Internet como un archivo mediante el navegador era una reliquia del pasado. Recordemos ahora que se nos dijo que, hasta que Linux no pudiera hacer lo mismo, no estaría preparado para la gente normal: ja-ja.
Dado que en el universo Linux hemos tenido "tiendas de aplicaciones" desde hace tiempo inmemorial (y el Ubuntu Software Center es bastante bueno), todo esto no nos importa demasiado. Pero no está de más preguntarse qué ocurrirá en un sistema operativo con una base de software más extensa y con una fuerte presencia de software privativo, como lo es la Mac App Store.
De momento, Apple no ha proporcionado mucha información sobre las ventas. Sin embargo, las compañías que venden software para Mac si que han dado algunos datos, y son como para dejar a cualquiera con la boca abierta: Pixelmator dice que ha ingresado 1$ millón en 20 días, Autodesk dice que ha vendido en 3 semanas el doble de copias de SketchBook Pro de las que esperaban para todo el año. RealMac vendió 5.000 copias de sus programas en dos días. Evernote ha doblado el número de nuevos usuarios. Hasta Microsoft esté pensando vender Office para Mac a través de ese canal. Por mucho HTML5 que uno se eche a la cabeza, está claro que la programación "tradicional" para escritorios está más viva que nunca, al menos en Mac. Por no decir que está viviendo una nueva edad de oro.
¿Por qué el simple hecho de pasar a vender mediante la App Store hace que las cifras se disparen? En su día ya se contó aquí la teoría económica. Por muchas y muy buenas aplicaciones que haya, por mucha gente que esté dispuesta a pagarlas, no habrá un intercambio comercial sin un mercado, sin un lugar donde la oferta y la demanda se vean cara a cara, como en una tienda cualquiera. El pago mediante tarjeta de crédito o paypal ya se usa mucho, pero deja mucho que desear frente a la alternativa de tener ante tus ojos un catálogo descomunal de aplicaciones, hacer click, y dejar que Apple se encargue del resto. Para mucha gente es más cómodo hacer click, pagar algunos euros por una aplicación cutre (o 200€ por una buena) y ser legal que molestarse en crackear, del mismo modo que muchos prefieren comprar música en iTunes a pesar de que podrían descargarla del emule. A más facilidad para "mercadear", mas ventas. Y puesto que los programadores ganan más dinero, se esfuerzan más por competir y programar cosas interesantes.
Ahondando en la herida, uno ve todos estos datos, y no puede evitar comparar y hacerse una idea de la enorme oportunidad que está perdiendo Microsoft, y del elefante inútil en el que Steve Ballmer lo ha convertido. Si Apple es capaz de tener éxito con una cuota de tan solo 1/10 de los ordenadores personales de EEUU (en otros países menos aun), ¿cuál sería el éxito de una buena tienda de aplicaciones para Windows? Atronador, pero visto lo visto tendremos que seguir esperando para comprobarlo. Lo peor de todo es que, aunque muchos no lo sabrán, Microsoft ya inauguró una tienda de aplicaciones...¡en 2004!
La interfaz era mala, la integración con Windows deficiente, en Vista era tan sólo una aplicación más del menú de inicio, y no estaba disponible para todos los países. En vez de mejorarla, Ballmer prefirió dedicarse a envidiar a Apple e inaugurar unas cuantas tiendas físicas (gran idea para una empresa de software, montar tiendas retail en las que se vende hardware de tus partners y copias legales del SO más preinstalado y crackeado del mundo). Luego, un buen día de 2008, decidieron cerrar Windows Marketplace y sustituirlo por la Microsoft Store, con casi todos los mismos fallos que la anterior. Y ahora siguen planeando una nueva tienda para Windows 8, que verá la luz vaya a saber usted cuando. Luego dicen por ahí que Steve Jobs es un genio, pero siendo realistas los competidores se lo han puesto bastante fácil.
28 de enero de 2011
13 de enero de 2011
Dos nuevas bajas en Oracle
Parece que Oracle no piensa perder ni un segundo en este 2011. La retahila de decepciones masivas por la gestión de las comunidades de software libre de Sun y del lenguaje Java no se ha acabado, ni mucho menos. En esta semana hay novedades respecto a los proyectos Hudson y Lustre.
El problema de Hudson en realidad ya empezó el año pasado. Hudson es, según su web, un software para monitorizar la ejecución de tareas repetitivas, especialmente compilación y testado continuo de proyectos (contado así parece una tontería, pero el proyecto tiene más de 300 plugins y parece ser bastante completo). Está escrito en Java, y tenía toda su infraestructura en java.net, propiedad de Sun/Oracle. La cual no iba muy bien, razón por la que los principales desarrolladores decidieron mover el correo a google groups y los repositorios a GitHub.
Un buen día, a Oracle se le ocurre migrar el proyecto a una nueva infraestructura de java.net sin consultar ni avisar apropiadamente (los emails de notificación no llegaron a los usuarios y desarrolladores), dejando a la comunidad completamente a oscuras. Tras unos días en esta situación, deciden acelerar la migración, lo cual provoca que un señor de Oracle, a base de labia hablando en nombre de los usuarios, diga sutilmente que Hudson no se mueve de java.net. Dice ser consciente de que no puede evitar que haya un fork de Hudson, pero advierte que el copyright y el trademark "Hudson" es de Oracle, y que no permitirán utilizarlo fuera de la comunidad. Conclusión: Los desarrolladores de Hudson deciden montarse una infraestructura propia, renombran el proyecto a "jenkins", e insisten en que ellos no quieren un fork e invitan, muy educadamente, a Oracle a unirse. ¿A que todo esto les suena?
El de Lustre tampoco es un caso nuevo. Lustre es un sistema de archivos distribuido - al estilo del GFS de Google o el Ceph de Linux- optimizado para clusters de ordenadores del tipo de los del Top 500. De hecho, los clusters gigantescos del Top 500 son sus principales usuarios (de los 30 más potentes, 15 usan Lustre; de los 100, 60). Lustre fue diseñado para Linux (de ahí viene la L de su nombre), está pensado para funcionar sobre Ext3/4, y aunque no ha sido incluido en el kernel -el código es público y GPL- es una de sus grandes y menos conocidas bazas. Pero he aquí que Sun compró Lustre en 2007, con el plan de hacerlo funcionar sobre ZFS. Y ahora está en manos de Oracle. ¿Y qué ha hecho Oracle con él? Adivínenlo.
No es oficial, pero parece ser que pasan de Lustre. Parece ser que van a cesar el desarrollo, así, sin más. Oracle no parece estar interesado en el mercado HPC. Pero aquí no ocurrirá lo de siempre. La gente que ejecuta esos clusters masivos con Lustre tiene algo de dinero, y mucho interés en que Lustre siga funcionando. Por eso hace ya unos meses formaron una fundación sin ánimo de lucro -OpenSFS- destinada a seguir apoyando el desarrollo de Lustre. En este caso, parece que la continuidad del proyecto está asegurada (y si no estuviera daría una oportunidad a Ceph, que parece una mejor opción a largo plazo).
Y bueno, estas son las noticias Oracle empezando el año. Esperemos que en lo que queda de él Ellison nos de algo más que disgustos.
El problema de Hudson en realidad ya empezó el año pasado. Hudson es, según su web, un software para monitorizar la ejecución de tareas repetitivas, especialmente compilación y testado continuo de proyectos (contado así parece una tontería, pero el proyecto tiene más de 300 plugins y parece ser bastante completo). Está escrito en Java, y tenía toda su infraestructura en java.net, propiedad de Sun/Oracle. La cual no iba muy bien, razón por la que los principales desarrolladores decidieron mover el correo a google groups y los repositorios a GitHub.
Un buen día, a Oracle se le ocurre migrar el proyecto a una nueva infraestructura de java.net sin consultar ni avisar apropiadamente (los emails de notificación no llegaron a los usuarios y desarrolladores), dejando a la comunidad completamente a oscuras. Tras unos días en esta situación, deciden acelerar la migración, lo cual provoca que un señor de Oracle, a base de labia hablando en nombre de los usuarios, diga sutilmente que Hudson no se mueve de java.net. Dice ser consciente de que no puede evitar que haya un fork de Hudson, pero advierte que el copyright y el trademark "Hudson" es de Oracle, y que no permitirán utilizarlo fuera de la comunidad. Conclusión: Los desarrolladores de Hudson deciden montarse una infraestructura propia, renombran el proyecto a "jenkins", e insisten en que ellos no quieren un fork e invitan, muy educadamente, a Oracle a unirse. ¿A que todo esto les suena?
El de Lustre tampoco es un caso nuevo. Lustre es un sistema de archivos distribuido - al estilo del GFS de Google o el Ceph de Linux- optimizado para clusters de ordenadores del tipo de los del Top 500. De hecho, los clusters gigantescos del Top 500 son sus principales usuarios (de los 30 más potentes, 15 usan Lustre; de los 100, 60). Lustre fue diseñado para Linux (de ahí viene la L de su nombre), está pensado para funcionar sobre Ext3/4, y aunque no ha sido incluido en el kernel -el código es público y GPL- es una de sus grandes y menos conocidas bazas. Pero he aquí que Sun compró Lustre en 2007, con el plan de hacerlo funcionar sobre ZFS. Y ahora está en manos de Oracle. ¿Y qué ha hecho Oracle con él? Adivínenlo.
No es oficial, pero parece ser que pasan de Lustre. Parece ser que van a cesar el desarrollo, así, sin más. Oracle no parece estar interesado en el mercado HPC. Pero aquí no ocurrirá lo de siempre. La gente que ejecuta esos clusters masivos con Lustre tiene algo de dinero, y mucho interés en que Lustre siga funcionando. Por eso hace ya unos meses formaron una fundación sin ánimo de lucro -OpenSFS- destinada a seguir apoyando el desarrollo de Lustre. En este caso, parece que la continuidad del proyecto está asegurada (y si no estuviera daría una oportunidad a Ceph, que parece una mejor opción a largo plazo).
Y bueno, estas son las noticias Oracle empezando el año. Esperemos que en lo que queda de él Ellison nos de algo más que disgustos.
5 de enero de 2011
Y Windows NT sobre ARM vio la luz...
Odio tener que publicar dos posts el mismo día, pero la ocasión lo merece. Ya es oficial, ya no es sólo un rumor: Windows 8 funcionará sobre ARM. Y también Office (y, es de esperar, más software de Microsoft).
Si recuerdan, un servidor ya habló aquí de la encrucijada que tenía Microsoft frente a los smartphones de última generación que han visto la luz tras el iPhone. Una de sus características es utilizar la misma base de sistema operativo y aplicaciones y APIs básicas que en los equipos de sobremesa, y ante eso Microsoft estaba retrasado, ya que dependía de Windows CE (y todo lo que elso representaba, como carecer de un navegador decente). Con Windows phone 7 optaron por crear un nuevo entorno de desarrollo, exclusivo .NET, ejecutado sobre CE.
Con el anuncio de Windows 8 sobre ARM, los planes de Microsoft parecen aclararse. Parece ser que Microsoft quiere usar este Windows 8 sobre ARM en tabletas, lo cual descarta que vayan a hacer una versión de Windows Phone 7, con CE. ¿Cual es su plan de futuro para ambos sistemas? Lo lógico, llegados a este punto, sería hacer lo mismo que han hecho sus competidores: Unificar todo. Primero, usando núcleo NT, y no el cacharrete de CE, para todos los dispositivos de consumo. Segundo, la plataforma de Windows Phone 7 debería poder ejecutarse sobre entornos NT sin problemas de compatibilidad, asi que lo lógico sería ver tabletas con Windows8-ARM utilizando aplicaciones de Windows Phone 7. ¿Se permitirán aplicaciones con la API Win32 pero en versión ARM? Dado que Microsoft va a portar Office, parece que si, pero habrá que esperar a más datos sobre la tienda de aplicaciones para windows.
Lo interesante de esto es que Microsoft va a tener que ganarse a los desarrolladores para que porten y programen para todas estas nuevas plataformas. La multinacional que supo ganarse el afecto de casi todos los desarrolladores del mundo ya quedó atrás, ahora esos desarrolladores admiran y llenan sus bolsillos con la Apple Store. ¿Quien va a recompilar software Win32 a ARM? Especialmente teniendo en cuenta que Microsoft parece dejadarlo cada vez más de lado en favor de .NET. También tendrá que convencer a los fabricantes de hardware de que adopten su sistema operativo, claro. Es uno de esos problemas en los que la pescadilla se muerde la cola.
También entra en juego el avance de ARM en servidores. En realidad, el que más sale perdiendo de todo esto es Intel. Quien iba a decirnos hace dos ó 3 años...
Si recuerdan, un servidor ya habló aquí de la encrucijada que tenía Microsoft frente a los smartphones de última generación que han visto la luz tras el iPhone. Una de sus características es utilizar la misma base de sistema operativo y aplicaciones y APIs básicas que en los equipos de sobremesa, y ante eso Microsoft estaba retrasado, ya que dependía de Windows CE (y todo lo que elso representaba, como carecer de un navegador decente). Con Windows phone 7 optaron por crear un nuevo entorno de desarrollo, exclusivo .NET, ejecutado sobre CE.
Con el anuncio de Windows 8 sobre ARM, los planes de Microsoft parecen aclararse. Parece ser que Microsoft quiere usar este Windows 8 sobre ARM en tabletas, lo cual descarta que vayan a hacer una versión de Windows Phone 7, con CE. ¿Cual es su plan de futuro para ambos sistemas? Lo lógico, llegados a este punto, sería hacer lo mismo que han hecho sus competidores: Unificar todo. Primero, usando núcleo NT, y no el cacharrete de CE, para todos los dispositivos de consumo. Segundo, la plataforma de Windows Phone 7 debería poder ejecutarse sobre entornos NT sin problemas de compatibilidad, asi que lo lógico sería ver tabletas con Windows8-ARM utilizando aplicaciones de Windows Phone 7. ¿Se permitirán aplicaciones con la API Win32 pero en versión ARM? Dado que Microsoft va a portar Office, parece que si, pero habrá que esperar a más datos sobre la tienda de aplicaciones para windows.
Lo interesante de esto es que Microsoft va a tener que ganarse a los desarrolladores para que porten y programen para todas estas nuevas plataformas. La multinacional que supo ganarse el afecto de casi todos los desarrolladores del mundo ya quedó atrás, ahora esos desarrolladores admiran y llenan sus bolsillos con la Apple Store. ¿Quien va a recompilar software Win32 a ARM? Especialmente teniendo en cuenta que Microsoft parece dejadarlo cada vez más de lado en favor de .NET. También tendrá que convencer a los fabricantes de hardware de que adopten su sistema operativo, claro. Es uno de esos problemas en los que la pescadilla se muerde la cola.
También entra en juego el avance de ARM en servidores. En realidad, el que más sale perdiendo de todo esto es Intel. Quien iba a decirnos hace dos ó 3 años...
Las novedades de Linux 2.6.37
Ya se ha anunciado la publicación de la versión 2.6.37 de Linux. Las novedades de esta versión son: mejoras de escalabilidad y rendimiento en Ext4 y XFS, posibilidad de desactivar el Big Kernel Lock, un dispositivo de bloques basado en el sistema de archivos distribuido Ceph, soporte para limitación del ratio de transferencia de E/S, varias mejoras en Btrfs, soporte en perf para analizar módulos y variables globales, compresión de la imagen de hibernación con LZO, soporte de PPP sobre IPv4, varias microoptimizaciones de la implementación TCP/IP, y muchos otros cambios menores y drivers nuevos. Lista completa en inglés en este enlace.
· Ext4: mejor escalabilidad SMP, mkfs más rápido:
· Mejoras de escalabilidad: En esta versión, Ext4 utilizará la capa llamada "bio" en lugar de otra llamada buffer". La capa "bio" (que es un alias de "block I/O": Se trata de la parte del kernel que se encarga de enviar peticiones al I/O scheduler) fue una de las primeras características que se incluyeron en Linux 2.5.1, y fue un reemplazo de la capa que sustituía, llamada "buffer", que tenía muchos problemas de escalabilidad y rendimiento: Al usarla, Ext4 sólo podía hacer peticiones de 4KB cada vez; utilizando la capa bio Ext4 puede enviar peticiones de 512KB cada vez. En el benchmark FFSB ejecutado en un equipo con 48 procesadores AMD y con almacenamiento de array RAID de 24 discos SAS, utilizando 192 threads paralelos de ffsb, la mejora fue del 300% http://thunk.org/tytso/blog/2010/11/01/i-have-the-money-shot-for-my-lca-presentation/
· mkfs más rápido: Una de las partes más lentas al crear un sistema de archivos Ext4 es inicializar la tabla de inodos. mkfs puede saltarse este paso y dejar las tablas sin inicializar. Cuando se monte el sistema de archivos por primera vez, el kernel creará un thread -ext4lazyinit- que inicializará las tablas.
· Mejoras de escalabilidad de XFS: Se ha mejorado la escalabilidad de cargas que operan con metadatos. Una máquina con 8 procesador ejecutando una instancia del benchmark fs_mark de 50 millones de archivos mejoró un 15%, y la eliminación de esos mismos archivos un 100%.
· Posibilidad de desactivar el Big Kernel Lock: El Big Kernel Lock (BKL) es un bloqueo gigante que fue introducido en Linux 2.0, cuando Alan Cox añadió por primera vez soporte para SMP. Pero fue sólo un paso para conseguir escalabilidad SMP - en Linux 2.0, solo un proceso podía ejecutar código del kernel a la vez, a largo plazo hay que reemplazar el BKL por múltiples bloqueos que abarquen pequeñas partes del código. En esta versión, por primera vez es posible compilar un kernel sin ningún tipo de soporte de BKL. Nótese que esto no tiene impacto en el rendimiento: todas las rutas de código críticas están libres de BKL desde hace mucho tiempo, pero quedaban muchos lugares no críticos -ioctls, drivers, sistemas de archivo poco conocidos- que continuaban usándolo por comodidad. Esos son los lugares donde se ha eliminado el uso del BKL, pero sólo ha sido sustituido por mutexes, que no mejoran el paralelismo.
· Dispositivo de bloques basado en el sistema de archivos distribuido Ceph: Ceph es un sistema de archivos distribuido que fue incluido en Linux 2.6.34. En el diseño de Ceph hay "dispositivos de almacenamiento de objetos", y "servidores de metadatos", que almacenan metadatos de los objetos. Ceph utiliza ambos para implementar su sistema de archivos; sin embargo esos objetos pueden utilizarse también para implementar un dispositivo de bloques exportable en red (o incluso almacenamiento de objetos compatible con Amazon S3)
Esta versión incluye el dispositivo de bloques Rados (RBD). RBD permite crear un dispositivo de bloques que esté repartido en red, apoyado sobre el almacenamiento de objetos distribuido de Ceph. A diferencia de alternativas como iSCSI o AoE, las imágenes RBD están replicadas varias veces y esparcidas en el cluster Ceph, proporcionando un dispositivo de bloques de red fiable (si un nodo falla, los otros siguen respondiendo) y escalable. RBD también soporta snapshots de sólo lectura con rollback, y también hay parches para crear en Qemu un dispositivo de bloques virtual que esté apoyado en un cluster Ceph.
· Limitación del ratio de transferencia de E/S: Se ha añadido soporte de límites de E/S, es decir la capacidad de especificar cuántos MB/s de escritura/lectura a un disco puede consumir, como mucho, un grupo de procesos. Esta capacidad es configurable mediante la interfaz cgroups. Ejemplo:
Montar cgroup de blkio:
# mount -t cgroup -o blkio none /cgroup/blkio
Especificar el ancho de banda en un dispositivo particular. El formato es ": "
# echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device
Esto pondrá un límite de 1MB/segundo a todos los procesos del cgroup en las lecturas del disco con los números de dispositivo 8:16.
Los límites también pueden especificarse en operaciones E/S por segundo (blkio.throttle.read_iops_device). También hay equivalentes para escritura: blkio.throttle.write_bps_device y blkio.throttle.write_iops_device. Esta característica no reemplaza el controlador de "peso" de E/S que fue incluido en 2.6.33.
· Jump label: Un punto de trazado podría describirse como un printf() especial, que se usa en el kernel para analizar el comportamiento del kernel mientras se ejecuta, para ello se utilizan herramientas como perf, LTT o systemtap. Hay dos tipos de puntos de trazado: dinámicos y estáticos. Los dinámicos modifican el código del kernel en tiempo de ejecución para insertar las instrucciones de CPU necesarias para obtener los datos. Esto es lo que systemtap hace cuando se intentan analizar puntos aleatorios del kernel. El nombre que se da a los puntos de trazado dinámico en Linux es "kprobes", y su impacto en el rendimiento ya fue optimizado en Linux 2.6.34.
Los puntos de trazado estáticos, en cambio, son insertados por los desarrolladores en puntos estratégicos del código. Por ejemplo, Ext4 tiene 50 puntos de trazado estático. Esos puntos son compilados junto al resto del kernel, y por defecto están desactivados - nadie los invoca hasta que alguien los active. Básicamente, una condición "if" que comprueba una variable. El impacto en el rendimiento es apenas notable, pero puede mejorarse, y eso es lo que se hace con "jump label": Se insertan instrucciones de CPU "no operación" en lugar de la comprobación condicional. De modo que un punto de trazado estático tiene sobrecarga cero. (Consejo: Puede utilizar el comando "sudo perf list" para ver la lista completa de puntos de trazado estático disponibles en su sistema)
· Novedades en Btrfs:
· Cacheado de la información de espacio libre en el disco: En esta versión, Btrfs almacena la información sobre las partes del disco que están libres en el propio disco, lo cual hace que cachear un grupo de bloques sea más rápido. Hasta ahora, cuando había que hacer asignaciones de espacio de un grupo de bloques que no había sido cacheado previamente, se tenía que escanear el árbol de extents (que representa las zonas del disco utilizadas por los archivos) por completo, para representar en las estructuras de memoria las zonas libres del disco. Ahora el espacio libre se escribe en el disco cada vez que se realiza una transacción. Esto supone un cambio en el formato de disco, pero no hay problemas de compatibilidad con los viejos kernels, ya que continuarán funcionando igualmente, con la diferencia de que generarán el caché del modo antiguo. También hay que tener en cuenta que esta característica está por el momento desactivada y tiene que activarse con la opción -o space_cache. También hay una opción -o clear_cache, útil solo para casos de depuración, que limpia los caches.
· Creación asíncrona de snapshots: Esto permite evitar tener que esperar a que un nuevo snapshot sea escrito al disco. Ha sido desarrollado teniendo en cuenta al demonio del sistema de archivos de Ceph, pero también está disponible para cualquier usuario añadiendo "async" al comando "btrfs subvolume snapshot"
· Permitir que un usuario sin privilegios elimine un subvolumen. Requiere utilizar la opción de montaje -o user_subvol_rm_allowed
· Cambiar el buffer de extents de un red-black tree a un radix tree, y utilizar RCU en lugar de spinlocks, lo cual mejora el rendimiento en algunos casos.
· Refinar la asignación de chunks: Soporte para grupos de bloques que puedan albergar datos+metadatos a la vez (util en dispositivos con poco almacenamiento), no asignar los chunks tan agresivamente (evita fallos de -ENOSPC debido a la sobreasignación de espacio para metadatos)
· Mejoras de perf probe: En esta versión se ha añadido soporte para mostrar las variables locales y globales en un punto determinado del código, mediante la opción "-V" (o "--vars"). Esto ayuda a buscar las variables locales que están disponible como argumentos de un evento determinado. Por ejemplo: "# perf probe -V call_timer_fn:23", mostrará las variables locales disponibles en ese punto de esa función. También es posible mostrar las variables globales con el parámetro "--externs". También se ha añadido soporte para analizar los módulos utilizando el parámetro "--module". Por ejemplo. "# ./perf probe --module drm drm_vblank_info:3 node m"
· Mejoras de gestión de energía: Compresión de la imagen de hibernación con LZO, autosuspensiones retrasadas:
· Autosuspensiones retrasadas: Esta es una característica que mejora a otra añadida en Linux 2.6.32, "runtime power management". Sin embargo, algunos drivers no quieren suspender el dispositivo tan pronto como sea posible, quieren que antes haya un periodo mínimo. Esto es lo que implementa esta característica.
· Compresión de la imagen de hibernación con LZO, que ayuda a comprimir y descomprimir más rápido la imagen.
· Soporte de PPP sobre IPv4: Esta versión incluye soporte de PPP sobre IPv4. Comparado con las implementaciones en espacio de usuario (poptop/pptpclient), mejora dramáticamente el rendimiento de las conexiones pptp vpn y reduce el consumo de CPU. Hay un proyecto accel-pptp project para utilizar este módulo.
Esta es la lista de novedades más importantes. La lista completa, en inglés, como siempre en este enlace.
· Ext4: mejor escalabilidad SMP, mkfs más rápido:
· Mejoras de escalabilidad: En esta versión, Ext4 utilizará la capa llamada "bio" en lugar de otra llamada buffer". La capa "bio" (que es un alias de "block I/O": Se trata de la parte del kernel que se encarga de enviar peticiones al I/O scheduler) fue una de las primeras características que se incluyeron en Linux 2.5.1, y fue un reemplazo de la capa que sustituía, llamada "buffer", que tenía muchos problemas de escalabilidad y rendimiento: Al usarla, Ext4 sólo podía hacer peticiones de 4KB cada vez; utilizando la capa bio Ext4 puede enviar peticiones de 512KB cada vez. En el benchmark FFSB ejecutado en un equipo con 48 procesadores AMD y con almacenamiento de array RAID de 24 discos SAS, utilizando 192 threads paralelos de ffsb, la mejora fue del 300% http://thunk.org/tytso/blog/2010/11/01/i-have-the-money-shot-for-my-lca-presentation/
· mkfs más rápido: Una de las partes más lentas al crear un sistema de archivos Ext4 es inicializar la tabla de inodos. mkfs puede saltarse este paso y dejar las tablas sin inicializar. Cuando se monte el sistema de archivos por primera vez, el kernel creará un thread -ext4lazyinit- que inicializará las tablas.
· Mejoras de escalabilidad de XFS: Se ha mejorado la escalabilidad de cargas que operan con metadatos. Una máquina con 8 procesador ejecutando una instancia del benchmark fs_mark de 50 millones de archivos mejoró un 15%, y la eliminación de esos mismos archivos un 100%.
· Posibilidad de desactivar el Big Kernel Lock: El Big Kernel Lock (BKL) es un bloqueo gigante que fue introducido en Linux 2.0, cuando Alan Cox añadió por primera vez soporte para SMP. Pero fue sólo un paso para conseguir escalabilidad SMP - en Linux 2.0, solo un proceso podía ejecutar código del kernel a la vez, a largo plazo hay que reemplazar el BKL por múltiples bloqueos que abarquen pequeñas partes del código. En esta versión, por primera vez es posible compilar un kernel sin ningún tipo de soporte de BKL. Nótese que esto no tiene impacto en el rendimiento: todas las rutas de código críticas están libres de BKL desde hace mucho tiempo, pero quedaban muchos lugares no críticos -ioctls, drivers, sistemas de archivo poco conocidos- que continuaban usándolo por comodidad. Esos son los lugares donde se ha eliminado el uso del BKL, pero sólo ha sido sustituido por mutexes, que no mejoran el paralelismo.
· Dispositivo de bloques basado en el sistema de archivos distribuido Ceph: Ceph es un sistema de archivos distribuido que fue incluido en Linux 2.6.34. En el diseño de Ceph hay "dispositivos de almacenamiento de objetos", y "servidores de metadatos", que almacenan metadatos de los objetos. Ceph utiliza ambos para implementar su sistema de archivos; sin embargo esos objetos pueden utilizarse también para implementar un dispositivo de bloques exportable en red (o incluso almacenamiento de objetos compatible con Amazon S3)
Esta versión incluye el dispositivo de bloques Rados (RBD). RBD permite crear un dispositivo de bloques que esté repartido en red, apoyado sobre el almacenamiento de objetos distribuido de Ceph. A diferencia de alternativas como iSCSI o AoE, las imágenes RBD están replicadas varias veces y esparcidas en el cluster Ceph, proporcionando un dispositivo de bloques de red fiable (si un nodo falla, los otros siguen respondiendo) y escalable. RBD también soporta snapshots de sólo lectura con rollback, y también hay parches para crear en Qemu un dispositivo de bloques virtual que esté apoyado en un cluster Ceph.
· Limitación del ratio de transferencia de E/S: Se ha añadido soporte de límites de E/S, es decir la capacidad de especificar cuántos MB/s de escritura/lectura a un disco puede consumir, como mucho, un grupo de procesos. Esta capacidad es configurable mediante la interfaz cgroups. Ejemplo:
Montar cgroup de blkio:
# mount -t cgroup -o blkio none /cgroup/blkio
Especificar el ancho de banda en un dispositivo particular. El formato es "
# echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device
Esto pondrá un límite de 1MB/segundo a todos los procesos del cgroup en las lecturas del disco con los números de dispositivo 8:16.
Los límites también pueden especificarse en operaciones E/S por segundo (blkio.throttle.read_iops_device). También hay equivalentes para escritura: blkio.throttle.write_bps_device y blkio.throttle.write_iops_device. Esta característica no reemplaza el controlador de "peso" de E/S que fue incluido en 2.6.33.
· Jump label: Un punto de trazado podría describirse como un printf() especial, que se usa en el kernel para analizar el comportamiento del kernel mientras se ejecuta, para ello se utilizan herramientas como perf, LTT o systemtap. Hay dos tipos de puntos de trazado: dinámicos y estáticos. Los dinámicos modifican el código del kernel en tiempo de ejecución para insertar las instrucciones de CPU necesarias para obtener los datos. Esto es lo que systemtap hace cuando se intentan analizar puntos aleatorios del kernel. El nombre que se da a los puntos de trazado dinámico en Linux es "kprobes", y su impacto en el rendimiento ya fue optimizado en Linux 2.6.34.
Los puntos de trazado estáticos, en cambio, son insertados por los desarrolladores en puntos estratégicos del código. Por ejemplo, Ext4 tiene 50 puntos de trazado estático. Esos puntos son compilados junto al resto del kernel, y por defecto están desactivados - nadie los invoca hasta que alguien los active. Básicamente, una condición "if" que comprueba una variable. El impacto en el rendimiento es apenas notable, pero puede mejorarse, y eso es lo que se hace con "jump label": Se insertan instrucciones de CPU "no operación" en lugar de la comprobación condicional. De modo que un punto de trazado estático tiene sobrecarga cero. (Consejo: Puede utilizar el comando "sudo perf list" para ver la lista completa de puntos de trazado estático disponibles en su sistema)
· Novedades en Btrfs:
· Cacheado de la información de espacio libre en el disco: En esta versión, Btrfs almacena la información sobre las partes del disco que están libres en el propio disco, lo cual hace que cachear un grupo de bloques sea más rápido. Hasta ahora, cuando había que hacer asignaciones de espacio de un grupo de bloques que no había sido cacheado previamente, se tenía que escanear el árbol de extents (que representa las zonas del disco utilizadas por los archivos) por completo, para representar en las estructuras de memoria las zonas libres del disco. Ahora el espacio libre se escribe en el disco cada vez que se realiza una transacción. Esto supone un cambio en el formato de disco, pero no hay problemas de compatibilidad con los viejos kernels, ya que continuarán funcionando igualmente, con la diferencia de que generarán el caché del modo antiguo. También hay que tener en cuenta que esta característica está por el momento desactivada y tiene que activarse con la opción -o space_cache. También hay una opción -o clear_cache, útil solo para casos de depuración, que limpia los caches.
· Creación asíncrona de snapshots: Esto permite evitar tener que esperar a que un nuevo snapshot sea escrito al disco. Ha sido desarrollado teniendo en cuenta al demonio del sistema de archivos de Ceph, pero también está disponible para cualquier usuario añadiendo "async" al comando "btrfs subvolume snapshot"
· Permitir que un usuario sin privilegios elimine un subvolumen. Requiere utilizar la opción de montaje -o user_subvol_rm_allowed
· Cambiar el buffer de extents de un red-black tree a un radix tree, y utilizar RCU en lugar de spinlocks, lo cual mejora el rendimiento en algunos casos.
· Refinar la asignación de chunks: Soporte para grupos de bloques que puedan albergar datos+metadatos a la vez (util en dispositivos con poco almacenamiento), no asignar los chunks tan agresivamente (evita fallos de -ENOSPC debido a la sobreasignación de espacio para metadatos)
· Mejoras de perf probe: En esta versión se ha añadido soporte para mostrar las variables locales y globales en un punto determinado del código, mediante la opción "-V" (o "--vars"). Esto ayuda a buscar las variables locales que están disponible como argumentos de un evento determinado. Por ejemplo: "# perf probe -V call_timer_fn:23", mostrará las variables locales disponibles en ese punto de esa función. También es posible mostrar las variables globales con el parámetro "--externs". También se ha añadido soporte para analizar los módulos utilizando el parámetro "--module". Por ejemplo. "# ./perf probe --module drm drm_vblank_info:3 node m"
· Mejoras de gestión de energía: Compresión de la imagen de hibernación con LZO, autosuspensiones retrasadas:
· Autosuspensiones retrasadas: Esta es una característica que mejora a otra añadida en Linux 2.6.32, "runtime power management". Sin embargo, algunos drivers no quieren suspender el dispositivo tan pronto como sea posible, quieren que antes haya un periodo mínimo. Esto es lo que implementa esta característica.
· Compresión de la imagen de hibernación con LZO, que ayuda a comprimir y descomprimir más rápido la imagen.
· Soporte de PPP sobre IPv4: Esta versión incluye soporte de PPP sobre IPv4. Comparado con las implementaciones en espacio de usuario (poptop/pptpclient), mejora dramáticamente el rendimiento de las conexiones pptp vpn y reduce el consumo de CPU. Hay un proyecto accel-pptp project para utilizar este módulo.
Esta es la lista de novedades más importantes. La lista completa, en inglés, como siempre en este enlace.
Suscribirse a:
Entradas (Atom)