Buscando, buscando, encuentro un foro donde indican que, en lugar de volcar la imagen en la primera partición se haga directamente en el dispositivo, es decir:

sudo dd if=fichero-imagen.iso of=/dev/disk2      
     # en lugar de /dev/disk2s1

Una vez termina, vuelvo a probar y LA COSA CAMBIA!!! Empieza a cargar algo, la pantalla se vacia y un par de segundos después vuelvo a la consola de OpenFirmware pero con el siguiente mensaje:

Can’t OPEN: cd:\install\yaboot

Algo es algo, parece que he dado un paso adelante… sólo falta llegar al yaboot

En todos los sitios donde he ido googleando y rebuscando para ver si encontraba alguien con el mismo problema en el que terminé, vi que no había sido el único en quedarme atascado en ese punto. Pero al fijarme, me dí cuenta de un detalle: busca el fichero de arranque en el ‘cd’ !!! ¿porqué si yo le he indicado que arranque desde el disk1 del puerto usb? ¿se podrá configurar?

Total, decido ver que hay dentro de la ISO que me he descargado e intento montarla (digo intento porque me da un error de “imagen de disco corrupta”, pero la monto igual, aunque en modo lectura) y editar el fichero /ppc/bootinfo.txt , aquí se indica que el fichero de arranque es

<boot-script>boot &device;:\install\yaboot<boot-script>
      # bingo!!  pero.. no puedo editarlo!!  

Sigo buscando y encuentro un “how-to” de ubuntu que indica que hay que convertir la imagen antes de volcarla en el pendrive:

hdiutil convert -format UDRW -o fichero-de-imagen-destino.img fichero-de-imagen-origen.iso

En mi caso no ha funcionado (y he bajado la 10.04, la 10.10, la 12.04 y la kubuntu-12.04 … dos veces!! para asegurarme que los ficheros son correctos) ya que la conversión finaliza con un “error 22″ y elimina la imagen… otro callejón sin salida!!

Sigo googleando y encuentro un hilo de depuración de ubuntu que dice que TODAS las imagenes de ubuntu para powerPC no son capaces de arrancar, y está confirmado (y corregido a partir de la 11.04)… pues no és, pq yo con la 12.04 tampoco he arrancado con el comando que busca \\:tbxi

Y entonces se me ocurre… ¿y si le indico DIRECTAMENTE que vaya al yaboot? pruebo…

dd if=imagen-ubuntu-12.04.iso of=/dev/disk2  
    # SIN indicar la particion

inicio OpenFirmware (comando-opcion-o-f)

boot usb1/disk@1:,\install\yaboot

######  FUNCIONA!!!  ######

Acabo de conseguir arrancar el liveCD (sin WiFi , en inglés y modo live… pero es un gran paso!!)

Tampoco he podido en algunas ocasiones instalar otra aplicaciones de escritorio por el mismo motivo, aunque en realidad es porque en la versión 10.5 se incluye el JavaVM 1.6 (que no está disponible oficialmente para Tiger)

Sin embargo, y viendo que el problema era la versión de Java pensé que tal vez había una esperanza… y buscando, buscando encontré un port de Java para Tiger (soylatte), que incluso se puede compilar (porque la que ofrece el desarrollador es para intel). Y si! Se puede instalar y tengo el ejecutable de java, pero no el Framework (al menos no organizado al “estilo MacOS”) y por tanto las aplicaciones se siguen quejando de lo mismo (aunque en la consola me diga: java version “1.6.0_03-p3″)

Ya casi me había rendido cuando se me ocurrió…. ¿¿¿ Y si me descargo un ubuntu en un pendrive y arranco desde el usb??? debería ser posible… pues manos a la obra!!

Lo primero, por supuesto, googlear un poco… tras mirar en algunos blogs y foros, y ver las soluciones y problemas que tiene la gente, empiezo por el principio: descargar una imagen (probaré con la Ubuntu 10.10 en versión PowerPC para Mac) y una vez bajada hay que pasarla al pendrive para lo que veo que la solución parece ser esto:

sudo umount /dev/disk2s1          
# desmonto la unidad USB que tengo conectada
#(en mi caso es disk2s1, pero miralo antes con df -h)

sudo dd if=/Volumes/Disco2/ubuntu-10.10-desktop-powerpc.iso of=/dev/disk2s1    
# la ruta es donde lo hayas descargado

El comando “dd” tardará mucho y no muestra ningún progreso, si quieres ver que está haciendo prueba a ejecutar esto desde otra consola:

ps aux | grep " dd "      
# con esto podrás ver el PID del proceso

sudo kill -INFO $PID_DD    
# esto le manda una señal que le hará volcar información
#de estado en la ventana donde esté ejecutando

Una vez copiado, me lo llevo al iBook APAGADO, lo conecto y enciendo pulsando Comando+Opción+O+F para acceder a la interfaz de OpenFirmware, accederemos a una pantalla de fondo blanco con una interfaz de consola de comandos de texto negro, ahí tecleo lo siguiente:

dev usb0

ls  #nada...

dev usb1

ls

ff9dc2c8: /disk@1      #bingo!

Pero tengo un problema… no puedo teclear la secuencia de arranque porque la disposición de teclado no tiene el símbolo “:”

Por suerte buscando he encontrado la disposición del teclado por defecto:

Ahora si, procedo a intentar el arranque:

dev disk@1

pwd /pci@f2000000/usb@1b/disk@1

boot /pci@f2000000/usb@1b/disk@1:,\\:tbxi 

Tras unos segundos cargando…

Warning: sector size mismatch! can't OPEN:  /pci@f2000000/usb@1b/disk@1:,\\:tbxi 

Can't open device or file

….se acabará aquí todo??? por hoy al menos si, que ya es muy tarde y mañana hay que trabajar…

Aún así, nada en esta vida es perfecto, e incluso Ubuntu puede fallar si lo apagas de cualquier manera.

La semana pasada, durante una presentación, y con el navegador a pantalla completa, se me quedó bloqueado el “maravilloso” firefox. Imposible recuperar su tamaño normal ni interactuar de ningún modo para cerrar la dichosa ventanita (también el hecho de tener en ese momento de un teclado reducido me impedía acceder a combinaciones de teclas que hubieran podido salvarme en ese momento). Pero de cualquier modo, y puesto que la situación necesitaba de una solución urgente, reinicié y arranqué un portátil que siempre está disponible para estos casos como solución auxiliar (y que por cierto, salvó el honor).

En cualquier caso, al reiniciar, aparecía el “fantástico” menú del grub. Al seleccionar la primera opción y arrancar… nada! o peor: la consola de shell con un sistema initramfs montado!! Aparecía en el log de arranque (bastante atrás, me costó encontrarlo), una linea en la que decía que el disco principal no podía ser montado porque necesitaba un check del disco y no podía usarse. Muy bien, entonces escribo: fsck /dev/sda ……     ¡¡PERO EN ESTA SHELL NO HAY COMANDOS DE CHECK DE DISCO!!! ¡¡¡PARA QUE NARICES ME SIRVE LA SHELL!!! La lista de comandos que muestra la ayuda es tan ridícula que con ella no se puede hacer nada. Se me ocurren dos cosas:

1. Indicar con un mensaje CLARO al final del log, justo antes de saltar a esa dichosa consola, PORQUÉ no arrancas. (esto es más que fácil, de hecho es la causa por la que para)
2. Incluir en esta imagen de memoria herramientas mínimas para poder corregir el problema (hay cantidad de distribuciones de Linux muy pequeñas, así que no será por espacio)

Pero en fin, visto que no podía arreglar el problema, me fui a internet (en otro pc, obviamente) y buscando y rebuscando (que tampoco entiendo que me costase tanto, porque este problema debe ser común) entre páginas de tíos que daban soluciones del estilo:

“edita el menú de grub para cambiar el UUID del disco por algo del estilo /dev/sdXX, hazlo con el comando sudo gedit /boot/grub/menu.lst“ (… sudo gedit??? en ese punto, cerraba esa página y a seguir buscando),

al final encontré un blog (del que ahora no recuerdo la dirección, así q no puedo enlazarlo, lo siento!) donde tras un discurso de desesperación parecido a este, hablaba de que había usado una distribución Live llamada RESCATUX que esperaba que le arreglase el problema. Decidí probar, no tenía nada que perder antes de tener que reinstalar.

Bajé la iso, la quemé en un CD, y arranqué con la esperanza de poder recuperar el pc “atascado”. Al iniciar, arrancó el escritorio (una Debian con Gnome… bien!  ) con una aplicación abierta con 3 opciones:

1. recuperar el menú grub en el mbr
2. actualizar el grub
3. chequear el disco
4. salir a la shell

La última, evidentemente, no me servía. Probé a chequear el disco, me daba a elegir el disco /dev/sda y luego nada. Así que opté por la primera, que me pidió donde restaurarlo y una vez seleccionada detectó que esa partición estaba pendiente de chequeo. Inició el chequeo, instaló el grub en su sitio y volvió a esa pantalla. Pues… listo, no? Reinicio, saco el CD y… al arrancar de nuevo, TODO PERFECTO!!!

Fantástico!!! Tengo ese CD guardado como oro en paño Ubuntu es genial… para cuando falla, hay otras distribuciones que te pueden salvar la vida

Generalmente, cuando alguien busca ayuda de como hacer esto o aquello en un entorno windows o mac, las instrucciones incluyen algún pantallazo (para ver la ventana que te sale) en la que se indica resaltado de algún modo el botón o check de opción que se debe marcar o pulsar. Y las instrucciones son del estilo de: pincha en “esto” y te saldrá esta ventana, pulsa en la pestaña “tal-y-cual”, y similares…

En cualquier distribución Linux (y a partir de ahora, me voy a enfocar en Ubuntu que será la que más probablemente tenga un recién llegado), lo que se puede hacer gráficamente viene “limitado” por las herramientas gráficas de que disponga la distribución (vamos, los programas instalados más los disponibles en los servidores de Ubuntu y que podemos instalar desde el “Gestor de paquetes Synaptic”). Cada uno de los programas que vemos como ventanitas gráficas, en realidad se traducen en uno o más procesos sobre el sistema operativo, y corresponde a la ejecución de un fichero (la aplicación) cuya interacción con nosotros es gráfica para permitir un control más sencillo de utilizar. Pero no necesariamente todo fichero ejecutable tiene porque tener una respuesta gráfica o visual, puede ser que simplemente permita ser “llamado”, ejecute su proceso y muestre un resultado final.

Pues bien, las aplicaciones ejecutables normalmente se abren con un doble-click sobre su icono desde el entorno gráfico. Esto en realidad no es más que una simplificación de lo que en realidad significa, que es llamar a ese fichero y ponerlo en ejecución. Y para eso no es imprescindible un entorno gráfico. Aquí es donde entra en juego la consola (o terminal) de comandos.

La consola de comandos (o terminal) no es más que otra aplicación (en Ubuntu: Aplicaciones > Accesorios > Terminal) que abre una nueva sesión de nuestro mismo usuario (es decir, que estamos conectados 2 veces a nuestro ordenador) en la que, en lugar del navegador de ficheros, tenemos un intérprete de comandos que espera ordenes textuales. Aquí es donde podremos ejecutar nuestros comandos (o los que indiquen como instrucciones en la página de ayuda que hayamos encontrado).

Existen infinidad de comandos disponibles comunes a todas las distribuciones (comandos GNU) y algunos específicos de la distribución que usemos (hay un pequeño tutorial en esta página del blog) que permiten un control mucho más directo y amplio sobre la máquina de lo que permiten los programas gráficos. Todos tienen la misma estructura:

<comando> <opciones>

El “comando” puede ser un comando interno del intérprete de comandos (hay una lista si escribís el comando “help”) o un fichero ejecutable (en este caso, puede ser sólo el nombre del fichero o la ubicación completa indicando los directorios donde está, algo así como: /usr/bin/lo_que_sea ).

Las “opciones” dependen totalmente del comando, cada uno tiene las suyas. Pero hay una serie de convenciones en todos los comandos GNU. De modo sencillo, las opciones se dividen en “modificadores” o “acciones” y “ficheros a los que aplica”. Los modificadores tienen la forma de un guión seguido de una letra (cuando hay varios, típicamente se agrupan en un sólo guión) o un doble guión seguido de un texto descriptivo de la acción. Generalmente suele existir la opción “-h” o “–help” para ver la sintaxis disponible del comando. Los ficheros pueden ser opcionales, dependerá de si la opción es aplicable a ficheros o no, pero de estar se debe indicar el nombre (o ubicación) del / los ficheros.

Si te fijas, verás que esto permite hacer muchísimo más que el entorno gráfico. Por ejemplo:

• rm  -Rf  /users  /home  /var =>    esto “borra” (rm) “recursivamente” (-R) y “forzadamente” (-f) las carpetas indicadas y su contenido (por lo de recursivo), las dos primeras suelen contener la carpeta del usuario (junto con el escritorio y la configuración gráfica) y la última contiene datos de trabajo de las aplicaciones (logs del sistema, cola de impresión, bases de datos, información de los paquetes instalados,  …). Vamos, que te cargas el sistema enterito.
• ren  jpeg  jpg  – /users/* => esto “renombra” (ren) cambiando el texto “jpeg” por el texto “jpg” en el nombre de todos los ficheros que hay en “/users” (hacer esto desde el entorno gráfico nos obligaria a cambiar una por una todas las imágenes)
• ls  -l  /users  /home  /var => esto “lista” (ls) en formato “largo” (-l) el contenido de las carpetas indicadas (sí, las 3 a la vez, una después de otra)
• man  ls => muestra el “manual” (man) del comando “ls” (sí, afortunadamente hay un manual para prácticamente todos los comandos disponibles)
• ….etc…

Sólo hay un par de cosas que se deben entender de este nuevo entorno:

• siempre estamos ubicados en un directorio (=carpeta) concreto, y los comandos que ejecutemos lo harán sobre ese directorio a menos que se indique lo contrario. (podemos saber donde estamos con el comando “pwd”)
• los comandos “sudo” y “su” permiten ejecutar lo que sea como si fueramos el superusuario (evidentemenete, nos pedirá la contraseña para verificar nuestra identidad), así que ojo con copiar y pegar aquí cualquier comando sacado de por ahí que empiece por ese prefijo

Espero que esto le sirva de algo a alguien.

Una revisión por capas basada en la estructura

Cuando se trata de sistemas de ficheros, Linux® es la navaja suiza de los sistemas operativos. Linux soporta un gran número de sistemas de ficheros, desde sistemas con diario (journaling) a clustering o criptográficos. Linux es una maravillosa plataforma para usar sistemas de ficheros estándar o los más exóticos, e incluso para el desarrollo de sistemas de ficheros. Este artículo explora el sistema de ficheros virtual (VFS por sus siglas en inglés) —algunas veces llamado el sistema de ficheros conmutador (switch) — en el kernel de Linux y después revisa algunas de las principales  estructuras que mantienen los sistemas de ficheros unidos.

Arquitectura básica de un sistema de ficheros

La aquitectura de sistema de ficheros de Linux es un ejemplo interesante de complejidad de abstracción. Usando un conjunto común de funciones de interfaz (API), una gran variedad de sistemas de ficheros pueden ser soportados con una gran variedad de dispositivos de almacenamiento. Tomemos, por ejemplo, la llamada a la función “leer” (read), que permite que cierto número de bytes sean leídos de un descriptor de fichero dado. La función “leer” no sabe nada de los tipos de sistemas de ficheros, tales como EXT3 o NFS. Tampoco sabe nada de medios de almacenamiento particulares sobre los que el sistema de ficheros está montado, tales como discos de tipo AT Attachment Packet Interface (ATAPI), discos Serial-Attached SCSI (SAS) o discos Serial Advanced Technology Attachment (SATA). Aun así, cuando la función “leer” es llamada para un fichero abierto, los datos son devueltos tal como se esperaba. Este artículo explora como se hace esto e investiga las principales estructuras de la capa de sistema de ficheros de Linux.

¿Qué es un sistema de ficheros?

Empezaré con una respuesta a la pregunta más básica, la definición de un sistema de ficheros. Un sistema de ficheros es una organización de datos y metadatos en un dispositivo de almacenamiento. Con una definición tan vaga como esa, ya se ve que el código requerido para soportarla será interesante. Como he dicho, hay muchos tipos de sistemas de ficheros y medios. Con todas estas variantes, cabe esperar que la interfaz de un sistema de ficheros Linux esté implementada como una arquitectura de capas, separando la capa de interfaz de usuario de la implementación del sistema de ficheros y de los controladores que manejan los dispositivos de almacenamiento.

Los sistemas de ficheros como protocolos

Otra manera de ver un sistema de ficheros es como un protocolo. Tal como los protocolos de red (p.ej., el protocolo IP) dar significado a las secuencias de datos atravesando la Internet, los sistemas de ficheros dan significado a los datos en un medio de almacenamiento particular.

Montaje

Asociar un dispositivo de almacenamiento a un sistema de ficheros en Linux es un proceso conocido como montaje (mounting). El comando “mount” es usado para adjuntar un sistema de ficheros a la actual jerarquía de sistema de ficheros (raíz, o root en inglés). Durante el montaje se debe indicar un tipo de sistema de ficheros, un dispositivo de almacenamiento que contenga un sistema de ficheros de ese tipo [Nota del traductor: en el texto original indica que debe ser un sistema de ficheros, pero eso no es exactamente así, por eso aquí está corregido] y un punto de montaje dentro de la jerarquía.

Para ilustrar las posibilidades de la capa de sistema de ficheros de Linux ( y el uso del comando mount ), se puede crear un sistema de ficheros en un fichero dentro del propio sistema de ficheros. Esto se consigue creando primero un fichero de un tamaño determinado usando el comando dd (copia un fichero usando /dev/zero como origen) — en otras palabras, un fichero inicializado con ceros, tal como se muestra en el Listado 1:

Listado 1. Creando un fichero inicializado a cero

$ dd if=/dev/zero of=file.img bs=1k count=10000

  10000+0 records in

  10000+0 records out
$

Ahora tenemos un fichero llamado “file.img” de 10MB de tamaño. A continuación, usaremos el comando “losetup” para asociar un dispositivo de bucle (loop) al fichero (para que funcione como un dispositivo de bloques en lugar de como un fichero normal dentro de un sistema de ficheros, es decir, lo convertimos en un dispositivo de almacenamiento):

$ losetup /dev/loop0 file.img

$

Con el fichero ahora como un dispositivo de bloques (representado por /dev/loop0), creamos un sistema de fichero en él con el comando mke2fs. Este comando crea un nuevo sistema de ficheros de tipo EXT2 del tamaño especificado, tal como se indica en el Listado 2:

Listado 2. Creando un sistema de ficheros EXT2 dentro de un dispositivo en bucle

 $ mke2fs -c /dev/loop0 10000

 mke2fs 1.35 (28-Feb-2004)

 max_blocks 1024000, rsv_groups = 1250, rsv_gdb = 39

 Filesystem label=

 OS type: Linux

 Block size=1024 (log=0)

 Fragment size=1024 (log=0)

 2512 inodes, 10000 blocks

 500 blocks (5.00%) reserved for the super user

 ...

 $

El fichero file.img, representado por el dispositivo de bucle (/dev/loop0), está ahora montado en el punto de montaje /mnt/point1 usando el comando mount. Destacar la especificación del sistema de ficheros como de tipo EXT2. Cuando esté montado, se puede tratar este nuevo punto de montaje como un nuevo sistema de ficheros usando el comando ls, tal como muestra el Listado 3:

Listado 3. Creando un punto de montaje y montando el sistema de ficheros a través de un dispositivo de bucle.

 $ mkdir /mnt/point1

 $ mount -t ext2 /dev/loop0 /mnt/point1

 $ ls /mnt/point1

 lost+found

 $

Como se muestra en el Listado 4, se puede continuar este proceso creando un nuevo fichero dentro del nuevo sistema de ficheros montado, asociando con un dispositivo de bucle, y creando otro sistema de fichero en él:

Listado 4. Creando un nuevo sistema de ficheros de bucle dentro de un sistema de ficheros de bucle.

 $ dd if=/dev/zero of=/mnt/point1/file.img bs=1k count=1000

 1000+0 records in

 1000+0 records out

 $ losetup /dev/loop1 /mnt/point1/file.img

 $ mke2fs -c /dev/loop1 1000

 mke2fs 1.35 (28-Feb-2004)

 max_blocks 1024000, rsv_groups = 125, rsv_gdb = 3

 Filesystem label=

 ...

 $ mkdir /mnt/point2

 $ mount -t ext2 /dev/loop1 /mnt/point2

 $ ls /mnt/point2

 lost+found

 $ ls /mnt/point1

 file.img lost+found

 $

A partir de esta simple demostración, es fácil ver lo poderoso que puede ser el sistema de ficheros de Linux (y el dispositivo de bucle). Puede usarse la misma aproximación para crear sistemas de ficheros encriptados con el dispositivo de bucle en un fichero. Esto es extremadamente útil para proteger tus datos mediante el montaje transitorio del fichero usando el dispositivo de bucle cuando sea necesario.

Arquitectura de sistema de ficheros

Ahora que hemos visto la construcción de un sistema de ficheros en acción, vuelvo a la arquitectura de la capa de sistema de ficheros de Linux. Este artículo muestra el sistema de ficheros de Linux desde dos perspectivas. La primera perspectiva es la de una arquitectura de alto nivel. La segunda excarva un poco más hondo y explora la capa de sistema de ficheros a partir de las estructuras principales que la implementan.

Arquitectura de alto nivel

Mientras que la mayoria del código de un sistema de ficheros existe en el nucleo (kernel en inglés) — excepto en el caso de los sistemas de ficheros del espacio de usuario, de los que hablaremos más tarde –, la arquitectura mostrada en la Figura 1 muestra las relaciones entre los principales componentes de un sistema de ficheros tanto en el espacio de usuario como en el núcleo.

Figura 1. Arquitectura de los componentes de un sistema de ficheros

El espacio de usuario (user space) contiene las aplicaciones (por ejempo, el usuario del sistema de ficheros) y las librerias GNU de C (glibc), que proveen la interfaz de usuario para las llamadas al sistema de ficheros (open, read, write, close). La interfaz de llamadas a sistema actua como un conmutador, concentrando las llamadas a sistema desde el espacio de usuario hacia los puntos de entrada apropiados dentro del espacio del núcleo (kernel space).

El VFS es el interfaz primario de los sistemas de ficheros subyacentes. Este componente exporta un conjunto de interfaces y después las abstrae para los sistemas de ficheros individuales, que pueden comportarse de maneras muy diferentes unos de otros. Existen dos cachés para los objetos del sistema de ficheros (inodos y entradas de directorio), que definiré brevemente. Cada una proveé un contenedor de objetos usados recientemente por el sistema de ficheros.

Cada implementación particular de un sistema de ficheros, tales como EXT2, JFS, etc., exporta un conjunto común de interfaces que son usadas (y esperadas) por el VFS. El buffer caché almacena peticiones entre el sistema de ficheros y los dispositivos de bloques que manipula. Por ejemplo, peticiones de lectura y escritura al dispositivo subyacente son pasadas a través del buffer caché. Esto permite que las peticiones sean cacheadas ahí para un acceso más rápido (en lugar de salir directamente hacia el dispositivo físico). El buffer caché es manejado como un conjunto de las listas menos usadas recientemente (LRU, por sus siglas en inglés). Es importante fijarse que se puede usar el comando sync para liberar todo el buffer caché hacia el medio de almacenamiento (para forzar la salida de todos los datos no escritos hacia los controladores de dispositivo, y a continuación hacia el dispositivo de almacenamiento).

Esta es la vista aérea de un VFS y de los componentes de un sistema de ficheros. Ahora echemos un vistazo a las principales estructuras que implementan este subsystema.

¿Qué es un dispositivo de bloques?

Un dispositivo de bloques es aquel en el que los datos que envia y recibe se mueven en bloques (tales como sectores de discos) y soporta atributos tales como buffering y acceso aleatorio (no es necesario que lea bloques secuencialmente, pero si que pueda acceder cualquier bloque en cualquier momento). Los dispositivos de bloques incluyen discos duros, CD-ROMs, y discos RAM. En contraste con los dispositivos de caracteres, de los que difieren en que ellos no tienen un medio fisicamente direccionable.  Los dispositivos de caracteres incluyen puertos serie y dispositivos de cinta, en los que los datos son secuenciados caracter a caracter.

Principales estructuras

Linux ve todos los sistemas de ficheros desde la perspectiva de un conjunto común de objetos. Estos objetos son el superbloque, el inodo, las entradas-D (dentry), y el fichero. En la raíz de cada sistema de ficheros está el superbloque, que describe y mantiene el estado del sistema de ficheros. Cada objeto que es gestionado dentro de un sistema de ficheros (fichero o directorio) está representado en Linux como un inodo. El inodo contiene todos los metadatos para gestionar objetos en el sistema de ficheros (incluyendo las operaciones que son posibles sobre él). Otro conjunto de estructuras, llamadas entradas-D (dentries), son usadas para hacer la traducción entre nombres e inodos, para los que existe una caché de directorios que mantiene los más recientemente usados. La entrada-D también mantiene las relaciones entre directorios y ficheros a través del sistema de ficheros. Finalmente, un fichero VFS representa un fichero abierto (mantiene un estado para el fichero abierto tal como el desplazamiento de lectura, y demás).

Capa del sistema de ficheros virtual (VFS)

El VFS actua como el nivel raíz de la interfaz de sistema de ficheros. El VFS mantiene registro de los sistemas de ficheros actualmente soportados, así como de aquellos sistemas de ficheros que están actualmente montados.

Los sistemas de ficheros pueden ser añadidos o eliminados de Linux dinámicamente usando un conjunto de funciones de registro. El núcle guarda una lista de los sistemas de ficheros actualmente soportados, que puede ser vista desde el espacio de usuario a través del sistema de ficheros /proc. Este fichero virtual también muestra los dispositivos actualmente asociados con algún sistema de ficheros. Para añadir un nuevo sistema de ficheros a Linux, se llama a la función register_filesystem. Ésta toma un único argumento que define la referencia a una estructura de sistema de ficheros (file_system_type), que define el nombre de un sistema de ficheros, un conjunto de atributos, y dos funciones de superbloque. Un sistema de ficheros también puede ser des-registrado.

Al registrar un nuevo sistema de ficheros, se ubica éste y la información pertinente sobre la lista file_systems (ver Figura 2 y linux/include/linux/mount.h). Esta lista define los sistemas de ficheros que pueden ser soportados. Se puede ver esta lista tecleando cat /proc/filesystems en la linea de comandos.

Figura 2. Sistemas de ficheros registros con el núcleo

Otra estructura mantenida en el VFS son los sistemas de ficheros montados (ver Figura 3). Esto proveé los sistemas de ficheros que actualmente están montados (ver linux/include/linux/fs.h). Esto enlaza con la estructura de superbloque, que exploraré a continuación.

Figura 3. Lista de sistemas de ficheros montados

Superbloque

El superbloque es una estructura que representa un sistema de ficheros. Incluye la información necesaria para manejar el sistema de ficheros durante las operaciones. Incluye el nombre del sistema de ficheros (tal como EXT2), el tamaño del sistema de ficheros y su estado, una referencia al dispositivo de bloques, e información de metadatos (tal como listas libres y demás). El superbloque es típicamente almacenado en el medio de almacenamiento pero puede ser creado en tiempo real si no existe uno. Se puede ver la estructura de superbloque (Figura 4) en linux/include/linux/fs.h.

Figura 4. Estructura de superbloque y operaciones de inodo

Un elemento importante del superbloque es la definición de las operaciones del superbloque. Esta estructura define un conjunto de funciones para manejo de inodos dentro del sistema de ficheros. Por ejemplos, los inodos pueden ser asignados con alloc_inode o eliminado con destroy_inode. Puedes leer y escribir inodos con read_inode and write_inode o sincronizar el sistema de ficheros con sync_fs. Se pueden encontrar la estructura de las super_operations (operaciones de superbloque) en /linux/include/linux/fs.h. Cada sistema de ficheros proveé sus propios métodos de inodos, que implementan las operaciones y proveén la abstracción común de la capa VFS.

inodo y entrada-d

El inodo representa un objeto en el sistema de ficheros con un identificador único. Cada sistema de ficheros particular proveé métodos para convertir un nombre de fichero en un identificador único de inodo y despues a una referencia a un inodo. Una porción de la estructura de un inodo se muestra en la Figura 5 junto con algunas de las estructuras relacionadas. Cabe notar en particular las estructuras inode_operations (operaciones sobre un inodo) y file_operations (operaciones sobre ficheros). Cada una de esas estructuras se refiere a las operaciones individuales que pueden ser ejecutadas sobre un inodo concreto. Por ejemplo, inode_operations define aquellas operaciones que operan directamente sobre un inodo, mientras que file_operations se refiere a aquellos émtodos relacionados con ficheros y directorios (las llamadas a sistema estándar).

Figura 5. La estructura de un inodo y las operaciones asociadas

Los inodos y entradas-d más recientemente usados son guardados en la caché de inodos y directorios respectivamente. Cabe destacar que para cada inodo en la caché de inodos hay una entrada-d correspondiente en la caché de directorios. Pueden encontrarse las estructuras de inodo y entrada-d definidas en ./linux/include/linux/fs.h

El caché de bloques (buffer caché)

Excepto en las implementaciones particulares de cada sistema de ficheros (que puede ser encontrada en ./linux/fs), la parte baja de la capa de sistema de ficheros es el buffer caché. Este elemento mantiene un registro de las peticiones de lecturas y escrituras de cada implementacion particular del sistema de ficheros y de los dispositivos físicos (a través de los controladores de dispositivos). Por cuestiones de eficiencia, Linux mantiene una caché de las peticiones para evitar tener que volver a ir al dispositivo físico para cada petición. En su lugar, los bloques (páginas) más recientemente usados son cacheados aquí para ser rápidamente devueltos al sistema de ficheros particular.

Sistemas de ficheros interesantes

Este artículo no va a extenderse explorando los sistemas de ficheros particulares que están disponibles para Linux, pero es importante hablar de ellos, aunque sea de pasada. Linux soporta un amplio abanico de sistemas de ficheros diferentes, desde los antiguos sistemas de ficheros tales como MINIX, MS-DOS, y ext2, hasta los nuevos sistemas de ficheros con bitácora (journaling) tales como ext3, JFS y ReiserFS. Adicionalmente, Linux soporta sistemas de ficheros criptográficos tales como CFS, y sistemas de ficheros virtuales tales como /proc.

Por último, un sistema de ficheros digno de mención es el sistema de ficheros dentro del espacio de usuario, o FUSE (por sus siglas en inglés). Este es un interesante proyecto que permite al usuario dirigir las peticiones al sistema de ficheros a través del VFS de vuelta hacia el espacio de usuario. De modo que si alguna vez has jugado con la idea de crear tu propio sistema de ficheros, este es un gran punto de inicio.

Conclusiones

Mientras que la implementación de un sistema de ficheros es cualquier cosa menos trivial, este es un gran ejemplo de una arquitectura escalable y extensible. La arquitectura de sistema de ficheros ha evolucionado a través de los años pero ha soportado exitósamente muchos tipos diferentes de sistemas de ficheros y muchos tipos de dispositivos de almacenamiento objetivo. Usando una arquitectura basada en conectores (plug-ins) con varios niveles de funciones indirectas, será interesante ver la evolución del sistema de ficheros de Linux en el futuro cercano.

Le pese a quien le pese, y lo diga quien lo diga, linux todavia no es un gran sistema de escritorio como lo pueden ser windows o mac, en ese sentido siguen ganando estos dos, ya que la sensación que tiene el usuario de poder controlar completamente su equipo y los recursos auxiliares de una manera relativamente sencilla es muy grande…

• Cualquier usuario de windows o mac sabe que si se compra una impresora nueva basta con instalarle una cosa llamada drivers y que permiten usarla (en algunos casos ni siquiera sera necesario), y una vez hecho eso ya la impresora funciona siempre correctamente.
• Cualquier usuario de windows o mac sabe que si se compra una cámara de fotos o cualquier otro aparato que lleve USB, bastará con instalarle previamente los drivers y luego el sistema ya conoce al aparatejo y podrá usarlo de una manera similar a como usa un disco externo o similar…
• Cualquier usuario de windows o mac sabe como instalar un programa, que le haces doble-clic al instalador, te aparecera un asistente que te dará instrucciones y que siguiendo las instrucciones al final tendrás instalado el software y podras usarlo sin haber tenido que hacer cosas extrañas (lease compilar, tocar registros o similares, ejecutar algo desde la consola, …)

Esto desde mi punto de vista son los 3 grandes caballos de batalla con los que aún tiene que lidiar cualquier distribución Linux (que no quiere decir que sean sus únicos handicaps, pero por lo que veo estos son los más importantes), y es cierto que últimamente ha mejorado muchísimo la cosa y se ha simplificado todo una barbaridad en cuanto a la impresión (en parte gracias al sistema CUPS de la gente de Apple), pero aún determinadas  impresoras no se reconocen de manera sencilla.

Hace poco tuve que instalar una impresora HP1018 en un PC con Ubuntu 8.04, pues bien, al buscar las impresoras me detectaba la impresora, de hecho el driver “se supone” que lo incluye la distribucion, pero la impresora no respondia a las paginas de prueba….

Googleando encontre una “joya” de script que instala un paquete extra y configura un par de cosas para permitir que el driver haga lo que toca: drivear   Funciona (comprobado!!) para la HP1018, y según el autor para la HP1000, HP1005 y HP1020 (estas no lo he podido comprobar). Copiais y pegais el código en un fichero .sh para bash, le dais permisos de ejecución y lo ejecutais como usuario  (os pedirá la contraseña para hacer sudo), después ya podeis configurar la impresora normalmente y tras reiniciar tanto el PC como la impresora todo irá como la seda

Suerte!!

Puesto que muchas veces la designación técnica de algunos elementos y algoritmos descritos en estos artículos suele ser la inglesa, sin que exista una traducción válida, adjuntaré a cada traducción literal que haga de estos conceptos el nombre original en inglés.

Y una vez expuestos estos dos puntos, empiezo con el cuerpo del artículo original.

Anatomía del asignador de losas (slab allocator) de Linux

[artículo original]

Un buen rendimiento del sistema operativo depende en parte de la habilidad del propio sistema para gestionar eficientemente los recursos. En los viejos tiempos, los gestores de pila (heap memory managers) eran la norma, pero el rendimiento se veia afectado por la fragmentación y la necesidad de reasignar memoria. Hoy, el núcleo de Linux® usa un método que fue originado en Solaris pero que ha sido usado en sistemas empotrados durante algún tiempo ya, asignando memoria como objetos basándose en su tamaño. Éste artículo explora las ideas tras el asignador de losas (slab allocator) y examina sus interfaces y sus usos.

Gestión de memoria dinámica

El objetivo de la gestión de memoria es proveer de un método por el cual la memoria pueda ser compartida de manera dinámica entre una variedad de usuarios para una variedad de propósitos. El método de gestión de memoria usado debería cumplir las dos siguientes premisas:

• Minimizar la cantidad de tiempo requerido para gestionar la memoria
• Maximizar la memoria disponible para uso general (minimizando la sobrecarga de gestión)

La gestión de memoria es, en última instancia, una suma nula de compensaciones. Se puede desarrollar un algortimo que use poca memoria para la gestión, pero al que le lleve mucho tiempo gestionar la memoria disponible. También se puede desarrollar un algoritmo que gestione la memoria muy eficientemente pero que use un poco más de memoria. Finalmente, los requisitos de una aplicación particular nos llevan al balance de compensaciones.

Los primeros gestores de memoria usaban una estrategia de asignación basada en pila. En éste método, un bloque grande de memoria (llamado pila) es usado para proveer memoria a los fines de cada usuario. Cuando los usuarios necesitan un bloque de memoria, hacen una petición de una determinada cantidad. El gestor de la pila mira en la memoria disponible (usando algún algoritmo particular) y devuelve el bloque. Algunos de los algoritmos usados en esta búsqueda son del tipo primer-ajuste (first-fit), en los que el bloque devuelto es el primero que se encuentre y que satisface la petición, o bien del tipo mejor-ajuste (best-fit), en los que el bloque devuelto es el que mejor se ajuste a la petición. Cuando los usuarios han terminado con la memoria, devuelven el bloque a la pila.

El problema principal con esta estrategia de asignación basada en pila es la fragmentación. A medida que se van asignando bloques de memoria, son devueltos en diferente orden y en diferentes instantes. Esto tiende a dejar agujeros en la pila haciendo necesario más tiempo para gestionar eficientemente la memoria libre. Éste algoritmo tiende a ser eficiente en consumo de memoria (ya que asigna exactamente lo que es necesario), pero requiere más tiempo para gestionar la pila.

Otra aproximación, llamada asignación de memoria del amigo (buddy memory allocation), es una técnica de memoria rápida que divide la memoria en un número de particiones potencia-de-2 y trata de asignar las peticiones de memoria usando una aproximación del tipo mejor-ajuste. Cuando la memoria es liberada por el usuario, el bloque amigo es chequeado para ver si alguno de sus vecinos colindantes han sido también liberados. Si es asi, los bloques son combinados para minimizar la fragmenteación. Éste algoritmo tiende a ser un poco más eficiente en tiempo pero puede desperdiciar memoria debido a la aproximación de mejor-ajuste.

Éste artículo se centra en la gestión de memoria del núcleo de Linux y, en particular, en los mecanismo provistos gracias a la asignación de losas (slab allocation).

La caché de losas (slab cache)

El asignador de losas usado en Linux se basa en un algoritmo originalmente creado por Jeff Bonwick para el sistema operativo SunOS. El asignador de Jeff gira en torno al cacheado de objetos. Dentro de un núcleo, una considerable cantidad de memoria es asignada para un conjunto finito de objetos tales como descriptores de ficheros y otras estructuras comunes. Jeff vió que la cantidad de tiempo requerido para inicializar un objeto ordinario en el núcleo excedía la cantidad de tiempo requerido para asignarlo y liberarlo. Su conclusión fue que, en lugar de retornar la memoria de vuelta al contenedor global, él hizo que la memoria siguiera inicializada para el propósito previsto. Por ejemplo, si la memoria había sido asignada para un exclusor mútuo (mutex), la función de inicialización (mutex_init) sólo necesita ser ejecutada una vez cuando la memoria es asignada por primera vez al exclusor mútuo. Subsiguientes asignaciones de la memoria no necesitarian ejecutar la inicialización porque ya se encontraria en el estado deseado desde la liberación previa y la llamada al destructor.

El asignador de losas de Linux usa estas ideas y otras para construir un asignador de memoria que es eficiente tanto en espacio como en tiempo.

La figura 1 ilustra el alto nivel de organización de las estructuras de losas. En el nivel más alto está la cadena de caché ( cache_chain), que es una lista enlazada de las cachés de losas. Esto es útil para los algoritmos de mejor-ajuste que buscan una caché que mejor se ajuste al tamaño de la asignación deseada (iterado sobre la lista). Cada elemento de la cache_chain es un puntero a una estructura kmem_cache (lo que llamamos una caché). Esto define un contenedor de objetos de un tamaño fijo para gestionar.

Figura 1. Las principales estructuras del asignador de losas

Cada caché contiene una lista de losas (slabs), que son bloques de memoria contiguos (típicamente páginas). Existen 3tres tipos de losas:

slabs_full

Losas que son asignadas completamente.

slabs_partial

Losas que son parcialmente asignadas.

slabs_empty

Losas que están vacías, o que son objetos no asignados.

Evidentemente las losas en la lista slabs_empty son los primeros candidatos para la recolecta (reaping). Este es el proceso por el cual la memoria usada por las losas es devuelta al sistema operativo para otros usos.

Cada losa en su lista es un bloque de memoria contiguo (una o más páginas contiguas) que es dividido en objetos. Estos objetos son los elementos fundamentales que se asignan y liberan de una caché en particular. Fijese en que la losa es la minima asignación posible del asignador de losas, así que si necesita crecer, ésta es la cantidad mínima en que crecerá. Típicamente, múltiples objetos son asignados en cada losa.

A medida que los objetos son asignados y liberados de una losa, la losa individual se puede mover entre las listas de losas. Por ejemplo, cuando todos los objetos son consumidos dentro de una losa, se mueve de la lista slabs_partial hacia la lista slabs_full. Cuando una losa está llena y un objeto es liberado, se mueve de la lista slabs_full hacia la lista slabs_partial. Cuando todos los objetos son liberados, se mueve desde la lista slabs_partial hasta la lista slabs_empty.

Motivación a favor de las losas

El asignador de caché de losas proveé una serie de beneficios sobre los esquemas tradicionales de gestión de memoria. Primero, los núcleos normalmente esperan múltiples asignaciones de los mismos pequeños objetos a lo largo del tiempo de vida del sistema. El asignador de caché de losas dispone de esto gracias al cacheado de objetos de tamaños similares, evitando de este modo el problema de la fragmentación que suele ocurrir. El asignador de losas también soporta la inicialización de objetos comunes, evitando así la necesidad de inicializar repetidamente un objeto para un mismo propósito. Finalmente, el asignador de losas soporta alineación y coloreado de caché por hardware, lo que permite a objetos en diferentes cachés ocupar las mismas lineas de caché para un incremento del uso de la caché y un mejor rendimiento.

Nota del traductor. A partir de éste punto, el artículo incluye código fuente y ejemplos prácticos sobre el código del slab caché allocator, lo que hace complicada y algo inútil su traducción. Teniendo en cuenta que la teoría ya ha sido expuesta y que lo importante para entender el concepto ya ha sido traducido, entiendo que si a alguien le interesa el resto sobre el código fuente, por favor se remita al artículo original, ya que la diferencia entre ese y como lo pueda yo traducir aquí será mínima y por tanto un esfuerzo inútil para mí. Espero de todas maneras que esta traducción le sirva a alguien para entender y tener claro el concepto del gestor de memoria usado por Linux.

Para los que, como yo, venimos del mundo RedHat y funcionamos con sistemas que han heredado su gestión de paquetes RPM, quizá nos parece algo incontrolable el hecho como apt-get gestiona las descargas, ya que simplemente te instala todas las dependencias que te hagan falta y la última versión de todo. Esto en una instalación de usuario típica es fantástico, porque de una manera sencilla configuras las actualizaciones automáticas y siempre estás al día sin preocuparte de que necesitas y si tienes que quitar este o aquel paquete para poder poner el nuevo. Pero en un sistema de servidor no es tan trivial: cambiar la versión de una determinada libreria o aplicación puede hacer que otra, que depende exactamente de aquella, deje de funcionar sin razón aparente.

En ese sentido, el sistema RPM es mucho más selectivo y te permite un mayor control de lo que tienes instalado, y te permite incluso definir desde donde lo quieres instalar (del DVD original, de internet, de un disco en otro ordenador…). Esta es la gran ventaja, a mi modo de ver, del sistema RPM: no necesitas una conexión a internet en cada PC, y esto en una red local de una empresa puede ser el escenario.

De cualquier modo, y teniendo en cuenta la posibilidad que tiene RPM de usar repositorios definidos en algún sitio, podemos emular el funcionamiento de actualización automática de apt-get.

[Nota: el HOWTO que viene a continuación se deberá ejecutar desde consola y como usuario root] 

Lo primero que deberemos hacer es asegurarnos que nuestra BDD de paquetes esté correcta y no presente incoherencias debido a un mal uso o posibles bugs en las aplicaciones que la manejen. Para esto tenemos el comando:

rpm –rebuilddb

Si todo está bien, no devolverá ninguna salida, pero si hubiera algún error mostrará los mensajes de lo que ha corregido. En ese caso, vuelve a ejecutar las veces que haga falta hasta que no produzca ninguna salida.  En casos extremos en que el mensaje sea que no se puede reparar la BDD, tendremos que reiniciarla:

cd /var/lib/rpm

rm -rf ??db.00*

rpm –rebuilddb

Una  vez que tengamos limpia y coherente nuestra BDD de RPMs, deberemos descargarnos la lista de repositorios de paquetes a los que posteriormente accederemos para actualizarnos. Primero eliminaremos todos los posibles repositorios (seguramente tendremos el DVD de instalación) que podamos tener:

urpmi.removemedia -a

Después, accedemos a la web EasyURPMI para obtener las direcciones de los repositorios adecuados a nuestra instalación y arquitectura. Son tres pasos, en el tercero obtendremos una lista de comandos que deberemos copiar y ejecutar en la consola para añadir los repositorios a nuestra lista (os recomiendo seleccionar la opción de índices comprimidos, así las descargas serán de unos cientos de K’s en lugar de unas decenas de M’s).

Una vez tengamos los repositorios descargados, deberemos proceder a la actualización de nuestro sistema. En adelante, y una vez hecho todo lo anterior, sólo deberemos lanzar este comando periódicamente si queremos mantener nuestro sistema actualizado:

urpmi –auto-select –force –auto

Podemos añadir algunas opciones más, como por ejemplo –no-install (para evitar la instalación, sólo se harán las descargas) o –keep (para mantener las versiones actualmente instaladas siempre que sea posible y no vaya en contra de las dependencias).

Espero que os sea de utilidad.

Se echa en falta en esos momentos un manual sencillo, no-completo (ya que una lista completa de todos los comandos GNU y de la shell que usemos es tan extensa que no sabríamos por donde empezar), y sobre todo centrada en lo esencial para poder empezar a movernos.

En ésta página voy a intentar formar una lista de comandos que puedan servir a cualquiera para empezar a moverse por la consola, evidentemente hay muchísimos más y seguramente me dejo alguno que alguien pueda pensar que es esencial. Pero creo que con éste listado se pueden realizar todas las funciones básicas del sistema, y aprender el resto sobre la marcha usando los manuales y la ayuda del sistema será sólo cuestión de tiempo y práctica, cosa que por otra parte resulta vital para moverse en éste entorno en el que debemos tener siempre buena memoria para recordar comandos, ubicaciones de ficheros, …

Se admiten todo tipo de correcciones y/o añadidos, que en todo caso podrían ir a parar a un listado de comandos avanzados. Espero que ésto pueda ser de utilidad a alguien.