Ya se ha anunciado (por diferentes canales)la versión 3.0 del kernel Linux.
Aparte de un nuevo sistema de numerar versiones, este kernel tiene unas cuantas novedades: defragmentación automática y 'scrubbing' de datos en Btrfs, envío de mensajes ICMP_ECHO sin privilegios, wake on WLAN, filtrado de paquetes BFP acelerado mediante JIT, soporte de XEN dom0, un sistema a lo memcached para el caché tde páginas, la llamada al sistema sendmmsg() que envía múltiples instancias de sendmsg(), la llamada al sistema setns() para gestionar mejor los sistemas de virtualización ligera, como los contenedores, soporte de nuevo hardware como por ejemplo Microsoft Kinect y APUs AMD Llano Fusion, y muchos otros drivers y pequeños cambios. La lista completa de
cambios, en inglés, puede encontrarse aquí, como siempre.
· Btrfs: defragmentación automática, scrubbing, mejoras de rendimiento
· Defragmentación automática: Los sistemas de archivos COW (copy-on-write, copiar-al-escribir) tienen muchas ventajas, pero también algunas desventajas, como por ejemplo la fragmentación. Cuando Btrfs escribe un archivo al disco por primera vez lo hace secuencialmente, pero el diseño COW implica que cualquier modificación posterior no debe reescribir los datos antiguos, sino escribirlos en un bloque libre del disco, lo cual causa fragmentación (las bases de datos RPM son un caso común de este problema). Además, están los problemas de fragmentación comunes a todos los sistemas de archivos. Btrfs ya ofrecía algunas alternativas para luchar contra este problema. En primer lugar, soporta defragmentación en vivo utilizando el comando "btrfs filesystem defragment". En segundo lugar, tiene una opción de montaje, -o nodatacow, que desactiva el COW para los datos. Ahora se añade una tercera opción, la opción de montaje -o autodefrag. Este mecanismo detecta pequeñas escrituras aleatorias en los archivos y los defragmenta automática y transparentemente, sin intervención del usuario. Aun no funciona bien con imágenes de virtualización o grandes bases de datos, pero funciona bien para los archivos pequeños como bases de datos rpm, sqlite o bdb.
· Scrubbing
"Scrubbing", que podría traducirse como "fregar", o "restregar", consiste en comprobar la integridad de todos los datos del sistema de archivos: Se van comprobando los checksums de todos los datos, y si hay alguno erróneo, o el disco está dañado, se restaura una copia en buen estado, de haberla.
· Mayor velocidad de creación/eliminación de archivos: Btrfs tiene bajo rendimiento en la creación/eliminación de archivos, la razón es que cada creación/eliminación necesita hacer modificaciones en el b+tree, como insertar o eliminar un item de inodo, de nombre de directorio, índice de directorio, etc. Ahora btrfs puede retrasar la inserción/eliminación de items en el b+tree, lo que permite acumular modificaciones y hacerlas todas de una vez. Los microbenchmarks de creación de archivos se han acelerado un ~15%, los de eliminación un 20%.
· No escribir al disco items de checksum de datos que no han cambiado: Mejora el rendimiento de fsync. Un benchmark sysbench haciendo "escritura aleatoria + fsync" ha aumentado de 112.75 peticiones/segundo a 1216 requests/seg.
· Asignador de espacio en configuraciones con múltiples discos: El asignador de "chunks" (el que busca espacio para usar en el disco) siempre asigna el espacio en las configuraciones multidisco en el mismo orden. Esto causa una distribución de los datos subóptima, especialmente usando RAID1/10 y un número impar de dispositivos. Ahora btrfs intenta buscar espacio en primer lugar en los discos con más espacio.
· sendmmsg(): acumulación de llamadas a sendmsg():
recvmsg() y sendmsg() son las llamadas al sistema que se utilizan para recibir/enviar datos a la red. En Linux 2.6.33 se añadió recvmmsg(), una llamada al sistema que permite recibir en una sola llamada al sistema los datos de varias llamadas recvmsg(), lo cual mejora el rendimiento y la latencia en muchos casos. Ahora, se ha añadido su equivalente sendmmsg(). Los microbenchmarks muestran una mejora de ancho de banda en el envío de tráfico UDP del 20% y un 30% en sockets raw.
· Soporte de Xem Dom0: Por fin, Linux tiene soporte del modo Dom0 de Xen, requisito para poder funcionar como host Xen sin parches.
· Cleancache: Cleancache es algo opcional que permite aumentar el rendimiento del caché de páginas del kernel. Podría describirse como algo análogo a memcached, pero para páginas de cache. Proporciona un almacenamiento no directamente direccionable por el kernel, que no garantiza que los datos que se escriban en él no desaparecerán. Puede ser usado por sistemas de virtualización para mejorar la gestión de memoria de las VMs, pero también puede usarse para implementar un caché comprimido.
· Filtrado de paquetes BPF mediante JIT: El filtrado de Berkeley Packet Filter, que es lo que utilizan herramientas como libpcap/tcpdump, normalmente se hace con un intérprete. En esta versión se ha añadido un JIT que genera código nativo para los filtros, y hace que el filtrado sea mucho más rápido. Aunque pueda parecer una exageración tener un JIT en el kernel, lo cierto es que se trata de un JIT muy, muy simple, y es algo que otros sistemas operativos, como FreeBSD, tienen desde hace años.
· Wake on WLAN: Wake-on-LAN es la capacidad de que un sistema dormido pueda ser "despertado" por un paquete de red especial. En esta versión se añade en la implementación 802.11 la misma capacidad, pero para tarjetas de red inalámbricas.
· Mensajes ICMP_ECHO sin privilegios: Esta versión permite enviar mensajes ICMP_ECHO (es decir, un ping) sin necesidad de privilegios de root, lo cual permite que la herramienta ping no requiera setuid.
· Llamada al sistema netns(): Linux soporta diferentes espacios de nombre para los diferentes recursos que gestiona; por ejemplo, las formas ligeras de virtualización, como los contenedores o systemd-nspaw, muestran a los procesos virtualizados un PID virtual en lugar del PID real. Lo mismo puede hacerse con la estructura de directorios del sistema de archivos, los recursos de red, IPC, etc. La única manera de configurar diferentes espacios de nombre es usar diferentes flags en la llamada al sistema clone(), pero ese método no permite hacer cierto tipo de cosas, como permitir que un proceso acceda al espacio de nombres de otro proceso. La llamada al sistema setns() resuelve ese problema.
· Temporizadores-alarma: Los temporizadores-alarma son temporizadores híbridos, similares a los temporizadores de alta resolución, sólo que cuando se suspende el sistema, se activa el RTC para que se dispare y despierte el sistema.Este concepto está inspirado en los temporizadores-alarma de Android, y la API usa la interfaz de relojería POSIX.
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.
22 de julio de 2011
15 de julio de 2011
Cómo instalar Fedora 15, u otra distro, sobre Btrfs como mandan los cánones
Hace ya meses que la cuenta de sectores relocalizados de mi disco duro (sectores dañados cuya referencia se modifica para que apunten a otros en buen estado) era demasiado preocupante, una especie de señal divina advirtiendo de que era hora de cambiar de disco, así que he aprovechado para conseguirle no un reemplazo, sino dos (con sus correspondientes ventiladores), y de ese modo dar a btrfs un hogar más apropiado.
Pero al comenzar una instalación nueva de Fedora 15, con ese inexplicable deseo de convertirla en espejo y honra de todos los administradores, me encontré con un problema que no había resuelto en la anterior instalación, y que ahora podía aprovechar resolver. Se trata de hacer, desde el principio, una instalación acondicionada para convivir con los subvolúmenes de btrfs.
En btrfs, los subvolumenes (que podrían describirse confusamente como pseudosistemas de archivos vacíos creados a partir del espacio disponible) son añadidos a la raíz del sistema de archivos como directorios. Una buena instalación sobre btrfs debería dejar ese directorio raíz exclusivamente para subvolúmenes, e instalar cosas dentro de estos. Por ejemplo, tendríamos un subvolumen "/raiz-fedora/" con la instalación de Fedora, otro "/raiz-debian/" con la de Debian, y un cursi "/casita/" para los datos personales. El problema está en que los instaladores de las distros no tienen nociones de subvolúmenes (Fedora los tendrá en la próxima versión), no permiten crearlos; y, lo que es más puntilloso, tampoco permiten montar unos que se hayan creado a mano fuera de la instalación, así que te instalan todo en la raíz principal. Se puede solucionar posteriormente a base copiar archivos y modificar el fstab, no digo que no, pero hay una alternativa, que cuento aquí porque no he logrado encontrarla en Google.
Resulta que btrfs permite configurar un subvolumen determinado como directorio raíz, es decir, podemos hacer que al montar el sistema de archivos, en lugar del directorio raíz contenedor de todos los subvolúmenes, monte /raiz-fedora o /raiz-debian. Así que, metidos en la tarea...
Con esto se crea un "pool" de almacenamiento consistente de esos dos discos, con la configuración de RAID0 (distribución) para datos y RAID1 (replicación) para metadatos (en un futuro se podrán tener diferentes políticas para cada subvolumen, pero de momento...)
Con esto se han creado los subvolúmenes requeridos.
Con esto se consigue que cada vez que se monte el sistema de archivos se monte directamente el subvolumen raiz-fedora, y no la verdadera raiz, que quedará oculta a primera vista (se puede volver a montar pasando a mount la opción -o subvolid=0). Ahora se puede instalar Fedora -con el DVD de instalación, no el Live, y pasando "btrfs" como opción del kernel-, y bastará indicar al instalador que se utilize /dev/disco1particion como raíz /: sin que el instalador se percate, estará instalando sus cosas en el subvolumen raiz-fedora.
Queda lo de poner al subvolumen casita como "/home". Una vez terminada la instalación, y antes de entrar por primera vez en la sesión, se puede entrar a una consola y modificar el /etc/fstab, añadiendo la línea correspondiente y, si apetece, adornar la de la raiz:
Tras esto, un reinicio, un mount -a o un montaje manual montará el subvolumen casita donde corresponde, aunque hay que acordarse de dar permisos adecuados al nuevo directorio /home (chmod o+rx /home). Ya puestos en la tarea, parecería apropiado crear el directorio del usuario que ya se había creado en los diálogos de inicio: mkdir /home/usuario; chown usuario:usuario /home/usuario - bonus para quien sea lo suficientemente diligente para, antes de montar el subvolumen en /home/, mover el directorio de usuario que la instalación había creado a, por ejemplo, /tmp, y devolverlo luego a su sitio natural.
Pero no se fíen, que siempre está SELinux para hacer la puñeta. Además de dar permisos a todos los usuarios en el nuevo montaje /home, es necesario darle el contexto SELinux adecuado, y también a /home/usuario, especialmente si quieren mover todos sus archivos personales de una instalación anterior. Así que queda un último comando: restorecon -R /home. Y, ahora si, todo completado.
Pero al comenzar una instalación nueva de Fedora 15, con ese inexplicable deseo de convertirla en espejo y honra de todos los administradores, me encontré con un problema que no había resuelto en la anterior instalación, y que ahora podía aprovechar resolver. Se trata de hacer, desde el principio, una instalación acondicionada para convivir con los subvolúmenes de btrfs.
En btrfs, los subvolumenes (que podrían describirse confusamente como pseudosistemas de archivos vacíos creados a partir del espacio disponible) son añadidos a la raíz del sistema de archivos como directorios. Una buena instalación sobre btrfs debería dejar ese directorio raíz exclusivamente para subvolúmenes, e instalar cosas dentro de estos. Por ejemplo, tendríamos un subvolumen "/raiz-fedora/" con la instalación de Fedora, otro "/raiz-debian/" con la de Debian, y un cursi "/casita/" para los datos personales. El problema está en que los instaladores de las distros no tienen nociones de subvolúmenes (Fedora los tendrá en la próxima versión), no permiten crearlos; y, lo que es más puntilloso, tampoco permiten montar unos que se hayan creado a mano fuera de la instalación, así que te instalan todo en la raíz principal. Se puede solucionar posteriormente a base copiar archivos y modificar el fstab, no digo que no, pero hay una alternativa, que cuento aquí porque no he logrado encontrarla en Google.
Resulta que btrfs permite configurar un subvolumen determinado como directorio raíz, es decir, podemos hacer que al montar el sistema de archivos, en lugar del directorio raíz contenedor de todos los subvolúmenes, monte /raiz-fedora o /raiz-debian. Así que, metidos en la tarea...
# mkfs.btrfs -d raid0 -m raid1 -L btrfspool /dev/disco1particion /dev/disco2particion
Con esto se crea un "pool" de almacenamiento consistente de esos dos discos, con la configuración de RAID0 (distribución) para datos y RAID1 (replicación) para metadatos (en un futuro se podrán tener diferentes políticas para cada subvolumen, pero de momento...)
# mount /dev/sdb /mnt; cd /mnt
# btrfs subvolume create raiz-fedora
Create subvolume './raiz-fedora'
# btrfs subvolume create casita
Create subvolume './casita'
Con esto se han creado los subvolúmenes requeridos.
# btrfs subvolume list /mnt
ID 256 top level 5 path raiz-fedora
ID 257 top level 5 path casita
# btrfs subvolume set-default 256 /mnt
Con esto se consigue que cada vez que se monte el sistema de archivos se monte directamente el subvolumen raiz-fedora, y no la verdadera raiz, que quedará oculta a primera vista (se puede volver a montar pasando a mount la opción -o subvolid=0). Ahora se puede instalar Fedora -con el DVD de instalación, no el Live, y pasando "btrfs" como opción del kernel-, y bastará indicar al instalador que se utilize /dev/disco1particion como raíz /: sin que el instalador se percate, estará instalando sus cosas en el subvolumen raiz-fedora.
Queda lo de poner al subvolumen casita como "/home". Una vez terminada la instalación, y antes de entrar por primera vez en la sesión, se puede entrar a una consola y modificar el /etc/fstab, añadiendo la línea correspondiente y, si apetece, adornar la de la raiz:
UUID=numero-raro / btrfs defaults,subvol=raiz-fedora 1 1
UUID=mismo-numero-raro /home btrfs defaults,subvol=casita 1 1
Tras esto, un reinicio, un mount -a o un montaje manual montará el subvolumen casita donde corresponde, aunque hay que acordarse de dar permisos adecuados al nuevo directorio /home (chmod o+rx /home). Ya puestos en la tarea, parecería apropiado crear el directorio del usuario que ya se había creado en los diálogos de inicio: mkdir /home/usuario; chown usuario:usuario /home/usuario - bonus para quien sea lo suficientemente diligente para, antes de montar el subvolumen en /home/, mover el directorio de usuario que la instalación había creado a, por ejemplo, /tmp, y devolverlo luego a su sitio natural.
Pero no se fíen, que siempre está SELinux para hacer la puñeta. Además de dar permisos a todos los usuarios en el nuevo montaje /home, es necesario darle el contexto SELinux adecuado, y también a /home/usuario, especialmente si quieren mover todos sus archivos personales de una instalación anterior. Así que queda un último comando: restorecon -R /home. Y, ahora si, todo completado.
14 de julio de 2011
Suscribirse a:
Entradas (Atom)