Archivo del mes de diciembre, 2009

Nuevo mirror de CentOS en Chile

30/12/09

centos-logoDesde hoy contamos con un nuevo mirror oficial de CentOS en Chile. Se trata de http://mirror.netlinux.cl/centos , donde están alojadas todas las arquitecturas disponibles para las versiones 4 y 5 de esta distribución de GNU/Linux.  El ancho de banda es de 100 mbps, y los protocolos de acceso habilitados son: http y rsync. Podrás encontrar más información acá.
Si tienes CentOS 4 y el plugin yum-plugin-fastestmirror, o CentOS 5 y el plugin yum-fastestmirror instalado y habilitado, entonces el discriminará cual es el mirror más conveniente de la lista. Y si quieres utilizar este mirror exclusivamente, agrégalo para cada repositorio en el archivo /etc/yum.repos.d/CentOS-Base.repo.

Linux 2.6.32

05/12/09

Fuente. http://diegocg.blogspot.com/2009/12/lo-que-trae-linux-2632.html

Resumen de las novedades más importantes del kernel Linux v2.6.32, que acaba de salir hoy: Reescritura de la parte de la VM encargada de enviar los datos al disco, considerables mejoras de Btrfs, muchas mejoras en los drivers gráficos, KSM (deduplicación de memoria en sistemas virtualizados), límites blandos en el controlador de memoria, soporte de la arquitectura S+Core, mejoras en la herramienta perf y otras muchas cosas. La lista completa, aquí, como siempre.

· Reescritura de la parte de la gestión de memoria encargada de escribir los datos al disco (“per-backing-device based writeback”): En el contexto de Linux, “writeback” puede definirse como el proceso de escribir la memoria “sucia” (memoria perteneciente a archivos modificados) del caché de páginas al disco. La cantidad de datos que pueden necesitarse escribir de una vez puede ser inmensa -cientos de MB, o incluso GB-, y el encargado de hacer el trabajo es un thread del kernel con el nombre de “pdflush”, que inicia su actividad cuando se alcanzan los límites definidos en /proc/sys/vm/* o como reacción a ciertas condiciones. Sin embargo, el actual sistema, pdflush, tiene varias desventajas, que lo hacen ineficiente en máquinas con múltiples discos y cuando se necesitan escribir grandes cantidades de datos. Jens Axboe (Oracle) ha diseñado un nuevo sistema que se basa en la idea de tener un thread de kernel dedicado a cada dispositivo y que maneja otro tipo de estructuras de datos que le permiten tomar mejores decisiones. Los threads “pdflush” son reemplazados con otros llamados “flush-MAJOR” (Major es el id “major” del dispositivo), que se crean cuando se escribe algo al disco y desaparecen automáticamente si no hay nada que hacer.

Este sistema tiene mejor rendimiento en muchos tipos de carga. En un benchmark de dos procesos haciendo escrituras secuenciales en un archivo de 32 GB ubicado en un volumen LVM con 5 discos “stripped”, XFS fue un 40% más rápido, y Btrfs 26% más rápido. Una carga basada en el benchmark ffsb que hace escrituras aleatorias fue un 8% más rápido sobre una sola unidad SATA típica. En un test en discos SSD sobre XFS fue un 20% más rápido, con un ratio de transferencia que se mantiene estable en 1GB/segundo, mientras que pdflush solo conseguía hacer 750 MB/s y con continua fluctuación de la velocidad. Las escrituras aleatorias a múltiples archivos tambien han mejorado, asi como las escrituras aleatorias mediante mmap(). En un test de un proceso escribiendo secuencialmente vs otro haciéndolo aleatoriamente pasó de unos pocos MB/s a 120 MB/s. Resumiendo, que el rendimiento mejora en muchos campos.

· Mejoras de Btrfs: En esta versión hay mejoras considerables en Btrfs:

· -ENOSPC: Hasta ahora, Btrfs no ha tenido verdadera capacidad de gestionar correctamente las situaciones en que el sistema se queda sin espacio libre (error -ENOSPC en varias funciones POSIX), debido a que estas situaciones son más dificiles de manejar en un sistema de archivos basado en técnicas COW que en uno tradicional donde simplemente se reescriben los bloques. En esta versión, Josef Bacik (Red Hat) ha añadido la infraestructura necesaria para solucionar ese problema. Nota: El sistema de archivos podría llenarse y, aun así, mostrar una cantidad considerable de espacio libre. Ese espacio viene de chunks de metadatos/datos que no pueden terminarse de llenar porque no hay espacio para crear su equivalente chunk de datos/metadatos. Este problema no tiene que ver con la gestión correcta de -ENOSPC, y será solucionada en futuras versiones

· Soporte adecuado de eliminación de snapshots y subvolúmenes: Usando la última versión de btrfs-progs se pueden encontrar herramientas para eliminar y renombrar snapshots y subvolúmenes sin tener que recurrir a rm -r. Este sistema es mucho más rápido, porque se hace la eliminación “caminando” el Btree. La implementación viene de manos de Yan Zheng (Oracle).

· Mejoras de rendimiento: Las escrituras secuenciales en hardware veloz se quedaban limitadas por el uso de CPU sobre los 400 MB/s, Chris Mason (Oracle) ha mejorado el código de manera que ahora es capaz de llegar a 1GB/s con la misma utilización de CPU que XFS (descontando los checksums). Hay tambien mejoras de velocidad en la escritura de grandes extents, y tambien en muchas otras cargas. Las configuraciones con múltiples dispositivos son tambien mucho más rápidas debido a los cambios en el sistema de writeback. La velocidad de fsync() tambien se ha mejorado considerablemente (soluciona un problema de lentitud de yum en Fedora 11)

· KSM (Kernel Samepage Merging), deduplicación de memoria en sistemas virtualizados: En los sistemas virtualizados, cada copia VM consume su memoria independientemente de las demás, y no puede compartirse a pesar de que una parte muy considerable es la misma en todas las instancias de un mismo SO. KSM es un sistema para compartir esa memoria. El thread del kernel ksmd escanea periódicamente areas de memoria, trata de identificar las que son idénticas, elimina las copias y solo conserva una. No toda la memoria es escaneada, solo las áreas especificadas por las utilidades de espacio de usuario mediante la llamada del sistema madvise(2) con el flag MADV_MERGEABLE.

El resultado es un dramático descenso de la memoria utilizada. En una prueba en un servidor de virtualización con KSM y 16 GB de RAM, Red Hat llegó a hacer funcionar 52 VMs con Windows XP y 1GB de memoria cada una. Este sistema fue diseñado para KVM, pero es agnóstico y puede utilizarse con cualquier otro sistema de virtualización, o incluso sin virtualización, por ejemplo en aplicaciones que por alguna extraña razón tengan varios procesos usando cada uno grandes cantidades de memoria que puede ser compartida en gran medida.

Para mayor informacion link de la noticia completa