[Traducido del artículo original de M.Tim Jones del 30 de octubre de 2007 para IBM]

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.

Haca tiempo que no escribía nada, ya que últimamente estoy trabajando bastante con equipos que usan Ubuntu y la verdad es que los problemas son mínimos y la gente que los usa estan encantados de la vida. Sin embargo, todavía hay algunas cosas que no funcionan tan simple como deberian, me estoy refiriendo por supuesto a ese gran “enemigo” de las distribuciones linux de escritorio: las impresoras.

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!!

Empiezo con éste una serie de artículos, traducidos de los originales de M.Tim Jones (mtj@mtjones.com) y que se pueden encontrar en el servicio de documentación técnica de IBM. Algunos de ellos ya tienen algunos meses de antigüedad, lamentablemente los he descubierto recientemente a partir del último publicado, pero los voy a ir traduciendo en el orden cronológico de publicación intentando traducir uno cada semana.

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.

Probablemente una de las causas por las que el usuario medio ha encontrado Ubuntu como una distribución atractiva frente a otras más clásicas es, además de por una buena selección de aplicaciones sencillas, el sistema Debian de actualización de software: apt-get.

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.

Existen una enorme cantidad de comandos de consola en el mundo *NIX, esto proporciona a éste entorno una potencia y flexibilidad increíbles pudiendo hacer absolutamente de todo y teniendo control absoluto sobre los procesos que lanzamos en nuestro sistema y sobre los ficheros que manejamos, así como sobre su contenido. Pero esta flexibilidad no es fácil de asimilar ni de controlar, y de hecho uno de los primeros problemas que se encuentra con el novato en el mundo Llinux suele ser un entorno hostil y extraño en el que debe dejar a un lado el ratón y tener en la memoria los comandos, ya que no hay iconos ni ayudas visuales, sólo una línea de comandos que espera pacientemente que se le diga qué debe hacer.

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.

[traducción del artículo original que se encuentra en ésta página]

Todos lo hemos hecho antes: accidentalmente tecleas el argumento incorrecto al hacer rm o seleccionas el fichero incorrecto para su borrado, al pulsar enter te das cuenta de tu error y tu estómago da un vuelco. Y cuando vas a buscar la copia de seguridad del sistema no hay ninguna.

Hay muchas herramientas de desborrado para sistemas FAT y NTFS, pero hay muy pocas para EXT3, que es actualmente el sistema de fichero por defecto de muchas distribuciones Linux. Esto es debido al modo en que los ficheros EXT3 son eliminados: información crucial que almacena donde está localizado el contenido del fichero es eliminada durante el proceso de borrado.

En este artículo, echaremos un vistazo a bajo nivel de porqué la recuperación es dificil y a algunas aproximaciones que son efectivas algunas veces. Usaremos herramientas de código abierto para la recuperación, pero las técnicas no son completamente automáticas.

¿Qué es un fichero?

Antes de poder ver como recuperar ficheros, necesitamos ver como se almacenan. Típicamente, los sistemas de ficheros están localizados dentro de particiones de disco, que a su vez está organizada en sectores (usualmente de 512 bytes). Cuando la partición está formateada usando EXT3, los sectores consecutivos son agrupados en bloques, cuyo rango puede variar entre 1024 y 4096 bytes. Los bloques son agrupados juntos en grupos de bloques, cuyo tamaño será de decenas de miles de bloques. Cada ficheros tiene sus datos almacenados en tres ubicaciones principales: bloques, inodos y entradas de directorio. El contenido del fichero se almacena en bloques, que son dispuestos para el uso exclusivo de ese fichero, expandiéndose por tantos bloques como sea necesario. Idealmente, el fichero debería utilizar bloques consecutivos, pero esto no es siempre posible.

Los metadatos del fichero son almacenados en una estructura de inodo, que se encuentra en una tabla de inodos colocada en el inicio de un grupo de bloques. Hay un número finito de inodos y cada uno es asignado a un grupo de bloques. Los metadatos de un fichero incluyen los datos temporales tales como la última modificación, el último acceso, el último cambio y la fecha de borrado. También incluye el tamaño del fichero, el identificador de usuario y de grupo, los permisos, y las direcciones de los bloques donde se puede encontrar el contenido del fichero.

Las direcciones de los primeros 12 bloques son guardadas en el inodo y las direcciones adicionales son almacenadas externamente en bloques, llamados bloques indirectos. Si el fichero requiere muchos bloques y no todas las direcciones caben en un bloque indirecto, un doble bloque indirecto es usado cuya dirección se incluye en el inodo. El doble bloque indirecto contiene direcciones de bloques indirectos simples, que contienen direcciones de bloques con datos de fichero. Hay incluso direcciones indirectas triples en el inodo que añaden una capa más de punteros.

Por último, el nombre del fichero está almacenado en una estructura de entrada de directorio ubicada en un bloque asignado al directorio padre del fichero. Un directorio EXT3 es parecido a un fichero y sus bloques contienen una lista de estructuras de entradas de directorio, cada una conteniendo el nombre de un fichero y las dirección del inodo en el que se almacenan los metadatos del fichero. Con el comando ls -i puedes ver la dirección del inodo que corresponde a cada nombre de fichero. Se puede ver la relación entre una entrada de directorio, el inodo y los bloques en la Figura 1.

Cuando un nuevo fichero es creado, el sistema operativo (SO) debe elegir que bloques e inodo asignará al fichero. Linux intentará asignar los bloques y el inodo en el mismo grupo de bloques que su directorio padre. Esto provoca que los ficheros en un mismo directorio estén mucho más cercanos. Posteriormente usaremos este hecho para restringir donde buscar datos eliminados.

El sistema de ficheros EXT3 tiene un journal (nota del traductor: me permito aquí mantener el término en inglés por comodidad en lugar de usar bitácora o diario de registro, ya que cualquiera de los dos queda algo raro) que registra las actualizaciones de los metadatos del sistea ANTES de que la actualización ocurra. En caso de una caída del sistema, el SO lee el journal y podrá reprocesar o deshacer las transacciones registradas para que la recuperación sea mucho más rápida que examinar cada estructura de metadatos, que era el antiguo y lentísimo mecanismo. Las estructuras de metadatos de ejemplo incluyen las entradas de directorio que almacenan nombres de fichero e inodos que almacenan los metadatos del fichero. El journal contiene el bloque entero que está siendo actualizado, no solo el valor que está cambiando. Cuando un nuevo fichero es creato, el journa debería contener la versión actualizada de los bloques que contienen la entrada del directorio y el inodo.

El proceso de borrado

Varias cosas ocurren cuando un fichero es borrado de un sistema EXT3 en Linux. Hay que tener en cuenta que el SO debe decidir exactamente que ocurre cuando un fichero es eliminado y éste artículo asume un sistema Linux general.

Como mínimo, el SO debe marcar cada uno de los bloques, el inodo y la entrada de directorio como no-asignados para que ficheros posteriores puedan usarlos. Esta mínima aproximación es lo que ocurría hace años con los sistemas EXT2. En ese caso, el proceso de recuperación era relativamente simple ya que el inodo aún contenía las direcciones de los bloques del contenido del fichero y herramientas tales como debugfs y e2undel podían re-crear el fichero fácilmente. Esto funcionaba mientras que los bloques no habían sido asignados a un nuevo fichero y el contenido original no había sido sobreescrito.

Con EXT3, hay un paso adicional que hace la recuperación mucho más difícil: cuando los bloques son desasignados, el tamaño del fichero y las direcciones de los bloques en el inodo son limpiados; por tanto ya no podemos determinar donde estaba el contenido del fichero. Podemos ver la relación entre la entrada de directorio, el inodo y los bloques de un fichero desasignado en la Figura 2.

Aproximaciones de recuperación

Ahora que conocemos los componente involucrados con los ficheros y cuales son limpiados durante el borrado, podemos examinar dos aproximaciones a la recuperación de ficheros (aparte de usar un backup). La primera aproximación usa el tipo de aplicación del fichero eliminado y la segunda aproximación usa los datos en el journal. Independientemente de la aproximación, debería dejar de usar el sistema de ficheros porque podría crear un fichero que sobreescriba los datos que está tratando de recuperar, puede detener su sistema y poner el disco en otro ordenador con un sistema Linux como un disco esclavo (slave) o arrancar desde un Linux LiveCD (knoppix o necromantux son buenas distribuciones para este tipo de tareas).

El primer paso para ambas técnicas es determinar la dirección del inodo del fichero eliminado. Esto puede ser determinado usando debugfs o The Sleuth Kit (TSK). Mostraré aquí el método usando debugfs ya que esta herramiento se incluye en muchas distribuciones Linux y es un depurador del sistema de ficheros. Para empezar con debugfs, debe saber el nombre del dispositivo de la partición que contiene el fichero eliminado. En mi ejemplo, he iniciado desde un LiveCD y el fichero está ubicado en /dev/hda5:

 # debugfs /dev/hda5

 debugfs 1.37 (21-Mar-2005)
 debugfs: 

Podemos usar el comando cd para cambiar al directorio del fichero eliminado:

 debugfs:  cd /home/carrier/ 

El comando ls -d listará los ficheros asignados y eliminados del directorio. Recuerde que la estructura de entrada de directorio almacena el nombre e inodo de los ficheros y este listado nos dará ambos valores ya que ninguno es eliminado durante el proceso de borrado. Los ficheros eliminados tendrán su dirección de inodo delimitado por “<” y “>”:

 debugfs: ls -d

 415848  (12) .    376097  (12) ..    415864  (16) .bashrc 
[...]

 <415926> (28 ) oops.dat 

(Nota: esta ultima linea deberia poner un 28 entre parentesis sin espacios dentro, pero aqui hay un espacio detras del 8 para evitar caritas sonrientes)

El fichero que estamos intentando recuperar es /home/carrier/oops.dat y podemos verlo previamente asociado al inodo 415,926. El “(28)” nos indica la longitud de la estructura de entrada de directorio, pero eso no nos interesa.

Recuperación por “esculpido” de ficheros (file carving)

La primera técnica de recuperación, llamada file carving (nota del traductor: mantendré el nombre en inglés), utiliza las firmas del fichero eliminado. Muchos tipos de ficheros tienen valores estándar en los primeros bytes de la cabecera del fichero, y ésta técnica de recuperación busca los valores de cabecera del fichero eliminado para determinar donde puede que empezara el fichero. Por ejemplo, los ficheros JPEG empiezan con 0xFFD8 y terminan con 0xFFD9. Para recuperar un fichero JPEG eliminado, deberíamos buscar en los dos primeros bytes de cada bloque hasta encontrarnos con la marca OxFFD8. Cuando encontrásemos ese bloque, deberíamos buscar un bloque con los bytes 0xFFD9 en él. Los datos intermedios se asume que era el fichero. Desafortunadamente, no todos los tipos de ficheros tienen una firma final, por tanto determinar el final es dificil. Un ejemplo de una herramiento de código abierto que hace file carving es foremost, también existen varias herramientas comerciales.

Podemos ejecutar una herramienta como foremost en un sistema de ficheros completo, pero acabaríamos probablemente con demasiados ficheros, incluyendo algunos ya asignados. Será preferible lanzarlo sobre cuantos menos datos sea posible. La primera manera en que podemos restringir el tamaño de los datos es examinar sólo los grupos de bloques donde el fichero estaba ubicado. Recuerde que los inodos y los bloques de un fichero están asociados a un mismo grupo de bloques, si hay espacio. En nuestro caso, sabemos que inodo usaba el fichero y por tanto podemos examinar sólo los bloques del mismo grupo. El comando imap en debugfs nos indicará a que grupo de bloques pertenece un inodo:

 debugfs:  imap <415926> Inode 415926 is part of block group 25

 located at block 819426, offset 0x0a80 

La salida del comando fsstat en TSK nos dirá también lo siguiente:

 # fsstat /dev/hda5 [...] Group: 25: Inode Range: 408801 - 425152 Block Range: 819200 - 851967

A continuación, necesitamos determinar los bloques que están en el grupo de bloques del fichero eliminado. Podemos verlos en la salida del comando fsstat mostrado anteriormente, pero si estuvieramos usando debugfs, necesitamos calcular el rango. El comando stats nos da el número de bloques en cada grupo:

 debugfs: stats [...] Blocks per group: 32768 [...]

Puesto que estamos buscando en el grupo de bloques 25, el rango de bloques va desde 819,200 ( 25 * 32,768 ) hasta el 851,967 ( 26 * 32,768 – 1 ). Si nos centramos sólo en estos bloques, estaremos mirando en 128Mb en lugar de en el sistema de ficheros completo. Aún así, si no podemos encontrar el fichero en estos bloques, necesitaremos mirar en todo el sistema de ficheros.

El siguiente paso para reducir los datos a analizar es extraer los bloques no asignados del sistema de ficheros ya que ahí es donde nuestro fichero eliminado estará. debugfs no nos permite actualmente extraer el espacio no asignado de sólo un grupo de bloques específico, por tanto deberemos usar la herramienta dls de TSK.

 # dls /dev/hda5 819200-851867 > /mnt/unalloc.dat 

El comando anterior nos guardará los bloques no asignados en el grupo de bloqes 25 en un fichero llamado /mnt/unalloc.dat . Asegurese que este fichero esté en un sistema de ficheros diferente ya que de otro modo podría acabar sobreescribiendo su fichero eliminado.

Ahora podemos ejecutar la herramienta foremost sobre los datos no asignados. foremost puede recuperar sólo tipos de ficheros para los que se haya configurado. Si foremost no tiene la firma de cabecera para el tipo del fichero eliminado, deberá examinar algunos ficheros similar y personalizar el fichero de configuración. Podemos ejecutarlo del siguiente modo:

 # foremost -d -i /mnt/unalloc.dat -o /mnt/output/ 

La opción -d intentará detectar que bloques son indirectos y no los incluirá en el fichero final. El directorio /mnt/output contendrá los ficheros que hayan podido ser recuperados. Si su fichero no está ahí, puede expandir su búsqueda a todos los bloques no asignados en el sistema de ficheros en lugar de sólo a los bloques del grupo.

Recuperación basada en journal

El segundo método para tratar de recuperar ficheros es usar el journal. Ya hemos visto que las actualizaciones de inodos se guardan primero en el journal, pero el concepto importante es que el bloque entero en el que el inodo está ubicado es guardado en el journal. Por tanto, cuando un inodo es actualizado, el journal contendrá copias de otros inodos almacenados en el mismo bloque. Versiones anteriores del inodo de nuestro fichero elimiando pueden existir en el journal porque otro fichero fuera actualizado antes del borrado.

La maner más fácil de buscar versiones anteriores del inodo es usando el comando logdump -i en debugfs:

 debugfs:  logdump -i <415926>
 Inode 415926 is at group 25, block 819426, offset 2688
 Journal starts at block 1, transaction 104588
 FS block 819426 logged at sequence 104940, journal block 2687
 (inode block for inode 415926):
 Inode: 415926   Type: regular        Mode:  0664   Flags: 0x0
 User:   500   Group:   500   Size: 2048000
 [...]
 Blocks:  (0+12): 843274 (IND): 843286
 [...] 

En este caso, podemos encontrar una copia previa del inodo y los bloques del contenido del fichero están listados en la última línea. La última línea muestra que el primer bloque del fichero es 843,274 y los siguientes 12 bloques en el sistema de ficheros son los siguientes 12 bloques del fichero. El fichero es grande y necesita un bloque indirecto, que está localizado en el bloque 843,286. Hasta aquí, todos los bloques son consecutivos y no había fragmentación. El bloque 843,286 contiene el resto de direcciones de bloques, así que podríamos buscar en una versión anterior para descubrir donde está ubicado el resto del fichero. Podemos ver si hay una copia en el journal usando logdump -b:

 debugfs:  logdump -b 843286 -c 

Desafortunadamente, no encontramos una copia del bloque que contiene la lista original de punteros de bloque así que, si queremos recuperar el fichero deberemos asumir que el resto del contenido del fichero está guardado en el bloque 843,287 y siguientes. Una aproximación más avanzada podría también considerar qué bloques están actualmente asignados y saltarnoslos. Los datos pueden ser extraidos con herramientas tales como dd o Linux Disk Editor. El journal puede ser consultado también usando las herramientas jls y jcat de TSK.

Conclusión

La recuperación de ficheros con EXT3 no es una tema trivial, lo que refuerza el concepto de la importancia de hacer copias de seguridad de los ficheros. Si el fichero no estaba fragmentado, la búsqueda de su firma de cabecera puede ser útil, pero la herramienta necesita saber ignorar los bloques indirectos y donde parar de copiar (no todos los ficheros tienen una marca de final de fichero). Restringiendo la búsqueda al grupo de bloques local puede ahorrar mucho tiempo. El journal puede ser útil si los ficheros cerca del fichero eliminado han sido reciéntemente actualizados y por tanto existe una versión previa del inodo, pero esto no está siempre garantizado y el bloque indirecto del fichero puede no existir.

Ya sé que esto no tiene que ver específicamente con linux, puesto que PHP es un lenguaje de programación multiplataforma, pero si es uno de los más usados en entornos linux para desarrollos web (evidentemente también hay otros como Perl, Python, Java, etc…). Por eso y por los problemas que pueden surgir con la codificación e internacionalización de caracteres es que creo que éste es un tema delicado.

Últimamente casi todas las distribuciones (mandriva 2007, ubuntu feisty, opensuse, …) funcionan enteramente de manera nativa con sistema utf-8 para evitar los típicos problemas con los “caracteres especiales”, o lo que los americanos/ingleses consideran que es especial simplemente porque no corresponde con su alfabeto. Muchas veces esos caracteres se pueden evitar, sobre todo en idiomas como el castellano o cualquier otro que use el mismo alfabeto, simplemente no incluyendo acentos, eñes, etc… pero otras veces es más complicado, no siempre se puede escribir según qué evitando todo eso. Y es peor en otros idiomas que usan distintos alfabetos, estos son los que promueven el uso del alfabeto utf-8 que es mucho más lógico.

El problema surge de la codificación interna que se hace de los caracteres: en el estándar ASCII el juego de caracteres es de 128 (esto incluye todo el alfabeto latino básico en minúsculas y mayúsculas, signos de puntuación, números, etc… pero no acentos, eñes, ç, etc…) y por tanto se pueden usar únicamente 7 bits para representar cualquier símbol ode la tabla; el ASCII extendido llega a 256 y contiene (dependiendo del código de página) los caracteres especiales de los alfabetos latinos de otros idiomas, y esto se guarda en 8 bits lo cual es comodísimo para manejar el texto y hacer cálculos sobre cadenas usando expresiones regulares o funciones sencillas. ¿¿¿Y que pasa con el resto??? ¿¿¿Debemos cambiar continuamente de página de códigos cada vez que nos aparezca un texto de otro sitio???

La solución la aportaron los desarrolladores de utf-8: codificación multibyte!! Esto es, una extensión del ascii, de modo que sea compatible con lo básico y para los caracteres extra se usan dos bytes pudiendo así guardar hasta 65535 caracteres diferentes. ¿¿¿Porqué no 65536 que es lo que permiten 16 bits??? Porque hace falta reservar un carácter que permita marcar que extendemos a 16 bits. También hay soluciones de tamaño fijo para los sistemas en que es habitual trabajar con más de 256 símbolos, estos no reservan nada y todos los caracteres representados ocupan 2 ó 3 bytes.

Todo esto no sería un problema si trabajasemos únicamente en nuestro ordenador de casita donde todo puede estar perfectamente sincronizado para funcionar siempre con el mismo juego de caracteres. Pero cuando desde PHP (o cualquier otro lenguaje) accedemos a una BDD o a un recurso remoto en otra máquina nos encontramos con el problema de no tenerlo todo en el mismo juego de caracteres, aquí es donde entran las herramientas de conversión, ya que PHP nativamente (al menos por ahora) no funciona en utf8 aunque sí es capaz de manejar los datos.

Aunque mejor de lo que lo he explicado yo, y con buenos ejemplos, lo explica ésta página que está en inglés pero que es muy completita.

“nmap” es una herramienta impresionante para configurar, explorar y verificar agujeros de seguridad en redes de todo tipo. Es multiplataforma y está disponible tanto a nivel de consola como en aplicaciones gráficas que le hacen de frontend (“knmap” y similares).

Si leemos la página de manual que tengamos en cualquier distribución linux sobre esta herramienta, veremos la infinidad de opciones y posibilidades que tiene, tantas que se hace muy dificil llegar a ser capaz de entender todo su potencial, sobre todo para alguien que no tenga mucha idea de cómo funciona el tráfico de red, las topologías, servicios, puertos, etc….

He encontrado éste artículo muy interesante en castellano sobre como utilizar este comando con todas sus opciones, desde cero las opciones que pueden ser más comunes, creo que vale la pena que le echeis un ojo.

Parece increíble poder mezclar estos tres conceptos, pero parece ser que el pingüino nos tenia reservada una pequeña sorpresa temporal, al menos en la versión x86-64 que no parece estar muy fina a pesar de llevar ya cierto tiempo en el mercado los procesadores a los que va destinado.

Vayamos al grano, tengo una máquina AMDX2 de 64 bits con un núcleo pre-compilado de la Mandriva2007 para x86-64. El rendimiento es más que aceptable, va muy rápido y no ha dado ningún problema salvo tener que encontrar todo el software que me ha hecho falta en la versión adaptada a esta arquitectura (para poder instalar via RPM, evidentemente podría, y lo he hecho con algún paquete, haber compilado los fuentes, pero no siempre es tan sencillo como pueda parecer)

En cualquier caso, hace unos dias he tenido serios problemas de “continuidad” con el funcionamiento de esta máquina, ya que me aparecían “kernels oops” que la reiniciaban o que la dejaban en un estado inestable en el que la mayoría de señales no funcionaban (fallaba algún subsistema y todo lo relacionado con él también). Los “oops” tenían que ver con IRQs, con E/S de disco cuando haciamos trabajo intensivo sobre él, etc…

Tras googlear un rato (como siempre, donde si no?), encontré varias soluciones de gente que parecía tener el mismo problema con los drivers de nVidia (no parecía muy relacionado!), no con ellos directamente sino con el tenerlos cargados en el kernel como módulos. Parece ser que los drivers de nVidia para arquitecturas x86-64 no están muy finos (por ser suaves y no decir que petan como unos desgraciaos), el caso es que encontré abundante material y soluciones temporales a los problemas que la gente tenía con las tarjetas gráficas. La única relación que ví con mi arquitectura era que en mi placa el chipset es nForce570 !!! (vaya, driver de nVidia para E/S)

• Una de las soluciones pasaba por retirar fisicamente memoria del sistema y dejarlo en 1 ó 2 GB (el tipo que tenía el problema tenía 4Gb igual que yo)… parece ser que le funcionó pero no tenía muy claro el porqué.
• Otra de las soluciones era pasar como parámetro al kernel mem=2G , alegando que los drivers de nVidia no estaban pensados nativamente para 64bits y que no se llevan muy bien con los límites de memoria de los 32bits… teniendo en cuenta que mi placa sólo detecta 3.8GB esta solución me pareció un buen camino a seguir, y la verdad es que funcionó, pero no sabía muy bien porqué.
• La respuesta la encontré en otro sitio donde hablaba de un parámetro del kernel que yo desconocía: report_lost_ticks
  

Este parámetro incluye en el dmesg los ticks (y los tacks… vamos todo lo relacionado con el reloj del sistema que no vaya bien) del kernel al hacer cosas. Muy interesante: con la opción de arranque normal un montón de mensajes de perdida de ticks, con la opción de 2G muchísimos menos, pero aún algunos… y los más curioso: al darle caña al procesador (haciendo trabajo en batch intensivo sobre la BDD) se perdían continuamente ticks de 2 en 2… consecuencia: el reloj corría que daba gusto, es decir en su propio eje temporal!! había encontrado la 5ª dimensión!!!

Al final, probando, probando, probé a cambiar el ventilador por otro más super-tochísimo (de 875gramos) que parece haber calmado a la cpu, pero que aún así no arregla el problema del tiki-taka…

No tengo una solución definitiva, solo esta orientación sobre los ticks para los que les pase algo similar con pc’s x86-64… [continuará?]