monografia sistema de archivos 20120916

Sistemas de Archivos. 2


Índice de contenido1. Introducción a los Sistemas de archivos......... ...........................52. Sistemas de archivos Linux para sistemas embebid os.........................7

2.1. Conceptos aplicados a los sistemas de archivo Linux....................72.2. Particiones................................... .........................72.3. i-nodos....................................... .........................8

2.3.1. Estructura de los i-nodos................... .......................92.3.2. Otras consideraciones de los i-nodos........ ......................10

2.4. Directorios................................... ........................102.5. Enlaces de archivos........................... ........................10

2.5.1. Enlaces duros o hard links.................. ......................112.5.2. Enlaces simbólicos o symbolic links......... ......................11

2.6. Sistema de archivos virtual................... ........................122.6.1. Estructura del sistema de archivos virtual.. ......................12

3. Sistema de archivos ext2........................ ..........................143.1. Montaje de un sistema de archivo.............. ........................143.2. Comprobación de la integridad del sistema de a rchivos.................15

4. Sistema de archivos ext3........................ ..........................174.1.Sistemas de archivos con journaling en Linux .. ........................174.2. Principales características del sistema de arc hivos ext3..............184.3. Integridad de los datos en ext3............... ........................204.4. Velocidad del sistema de archivos ext3........ ........................204.5. Otras ventajas del ext3....................... ........................21

5. Sistema de archivos ext4........................ ..........................225.1.Mejoras introducidas en el ext4................ ........................22

5.2.Cómo empezar a trabajar con el ext4............ ........................235.2.1.Creación de un nuevo sistema de archivo Ext4. ......................235.2.2.Migración de sistemas de archivos ext3 a ext4 ......................235.2.3.Montaje de un sistema ext4 sobre un sistema e xt3...................24

6. Sistema de archivos ReiserFS.................... ..........................256.1.Funcionalidades del sistema ReiserFs........... ........................25

7. Sistema de archivos JFFS2....................... ..........................268. Sistema de archivos cramfs...................... ..........................289. Sistema de archivos de red...................... ..........................30

9.1.Sistema de archivos raíz en NFS................ ........................3110. Pseudo sistemas de archivos.................... ..........................33

10.1. Pseudo sistema de archivos proc.............. ........................3310.2. Pseudo sistema de archivos sysfs............. ........................35

11. Otros sistemas de archivos..................... ..........................3712. Construcción de un sistema de archivos simple.. ..........................3813. Bibliografía y Agradecimientos................. ..........................39

13.1.Bibliografía.................................. ........................3913.2.Agradecimientos............................... ........................39


Acrónimos

Meta datos: Son características del archivo, en contraposición a los datos del archivo en sí. Los mismos incluyen la fecha de un a rchivo, el tiempo, el tamaño, los bloques utilizados, etc.

VLF: Virtual file system, sistema de archivos virtual.

Journaling file: Archivo diario, utilizado en los sistemas de archi vos journaling o de diario, para llevar un control de l as transacciones que ocurren en el sistema y poder recuperarse rápidamente en ca so de fallo.


1. Introducción a los Sistemas de archivos

Los sistemas de archivos (filesystem en inglés), estructuran la información guardada en una unidad de almacenamiento (normalmente un disco duro de una computadora), que luego será representada ya sea textual o gráficamente utilizando un gestor de archivos. La mayoría de los sistemas operativos poseen su propio sistema de archivos.

Lo habitual es utilizar dispositivos de almacenamiento de datos que permiten el acceso a los datos como una cadena de bloques de un mismo tamaño, a veces llamados sectores, que pueden ser, por ejemplo, de 512 bytes de longitud. El software del sistema de archivos es responsable de la organización de estos sectores en archivos y directorios y mantiene un registro de qué sectores pertenecen a qué archivos y cuáles no han sido utilizados. En la práctica, un sistema de archivos también puede ser utilizado para acceder a datos generados dinámicamente, como los recibidos a través de una conexión de red (sin la intervención de un dispositivo de almacenamiento).

Los sistemas de archivos tradicionales proveen métodos para crear, mover, renombrar y eliminar tanto archivos como directorios, pero carecen de métodos para crear, por ejemplo, enlaces adicionales a un directorio o archivo (enlace duro en Unix) o renombrar enlaces padres (".." en Unix).

Un archivo es una abstracción muy importante en informática. Los archivos sirven para almacenar datos de forma permanente y ofrecen un pequeño conjunto de primitivas muy potentes (abrir, leer, avanzar puntero, cerrar, etc.). Los archivos se organizan normalmente en estructuras de árbol, donde los nodos intermedios son directorios capaces de agrupar otros archivos. El sistema de archivos es la forma en que el sistema operativo organiza, gestiona y mantiene la jerarquía de archivos en los dispositivos de almacenamiento, normalmente discos duros. Cada sistema operativo soporta diferentes sistemas de archivos. Para mantener la modularización del sistema operativo y proveer a las aplicaciones con una interfaz de programación (API) uniforme, los diferentes sistemas operativos implementan una capa superior de abstracción denominada Sistema de archivos Virtual (VFS: Virtual File System). Esta capa de software implementa las funcionalidades comunes de los diversos sistemas de archivos implementados en la capa inferior.

El acceso seguro a sistemas de archivos básicos puede estar basado en los esquemas de lista de control de acceso o capacidades. Las listas de control de acceso hace décadas que demostraron ser inseguras, por lo que los sistemas operativos experimentales utilizan el acceso por capacidades. Los sistemas operativos comerciales aún funcionan con listas de control de acceso.

Figura 1-1: Ubicación de los sistemas de archivos dentro de los sistemas operativos.

El modelo general de archivos puede ser interpretado como orientado a objetos, donde los objetos son construcciones de software (estructura de datos y funciones y métodos asociados) de los siguientes tipos:

• Súper bloque: mantiene información relacionada a los sistemas de archivos montados. Está representado por un bloque de control de sistema almacenado en el disco (para sistemas basados en disco).


• i-nodo: mantiene información relacionada a un archivo individual. Cada i-nodo contiene la meta-información del archivo: propietario, grupo, fecha y hora de creación, codificación y último acceso, más un conjunto de punteros a los bloques del disco que almacenan los datos del archivo. Almacena toda la información acerca del archivo excepto el archivo en sí.

• Archivo: mantiene la información relacionada a la interacción de un archivo abierto y un proceso. Este objeto existe sólo cuando un proceso interactúa con el archivo.

• Dentry: enlaza una entrada de directorio (pathname) con su archivo correspondiente. Los objetos "dentry" recientemente usados son almacenados en una caché (dentry caché) para acelerar la translación desde un nombre de archivo al i-nodo correspondiente.

Figura 1-2: Esquema completo del sistema de almacenaje de datos.


2. Sistemas de archivos Linux para sistemas embebido s

Tal vez una de las decisiones más importantes que un diseñador de sistemas embebidos hace es que sistema de archivos debe implementar. Algunos sistemas de archivos están diseñados para optimizar el rendimiento, mientras que otros para optimizar el tamaño, y otros para optimizar la recuperación de datos después de una falla en el dispositivo o de energía.

En las siguientes secciones se presenta los principales sistemas de archivos en uso, en sistemas Linux y examina las características de cada uno que se aplican a diseños embebidos. Comenzando con el sistema de archivos más popular, en uso en anteriores distribuciones Linux de escritorio, presentamos conceptos usando la segunda versión del sistema de archivos extendido (ext2: del inglés “Extended File System”) para sentar algunas bases para futuros debates. Luego nos fijamos en su sucesor, la tercer versión del sistema de archivos extendido (ext3), que es el sistema de archivos por defecto para muchas de las distribuciones de Linux de escritorio más populares de hoy en día. Después de la introducción de algunos de los fundamentos, se analiza una variedad de sistemas de archivos especializados, en particular los optimizados para la recuperación de datos y de espacio de almacenamiento, y los destinados para el uso en dispositivos de memoria Flash. El sistema de archivos de red (NFS) se presenta, seguido por una discusión de los Pseudo sistemas de archivos, más importantes incluyendo el sistema de archivos proc y sysfs.

Los sistemas de archivos soportados por Linux se clasifican en tres categorías:

1. Basados en disco: discos duros, disquetes, CD-ROM, etc. (Estos sistemas son ext2, ext3, ext4, ReiserFS, XFS, JFS, ISO9660, etc.).

2. Sistemas remotos (de red): NFS, Coda, Samba, etc.3. Sistemas especiales: procfs, ramfs y devfs.

2.1. Conceptos aplicados a los sistemas de archivo Linux

Antes de ahondar en los detalles de los sistemas de archivos individuales, se verá un panorama general de cómo se almacenan datos en un sistema Linux. En general, los dispositivos de almacenamiento, guardan y/o recuperan los datos en forma de cadenas de caracteres en serie. El ejemplo más básico de un dispositivo de caracteres es un puerto serie o unidad de cinta magnética. En contraste, los dispositivos de bloque, almacenan y recuperan datos en forma de bloques de igual tamaño. Por ejemplo, un controlador de disco duro IDE típico puede transferir 512 bytes de datos a la vez desde una ubicación direccionable, específica en el medio físico. Los sistemas de archivos están basados en dispositivos de bloque.

Cada sistema de archivos Linux ha implementado un conjunto básico de conceptos comunes derivados del sistema operativo Unix. Los archivos se representan por nodos, los directorios son simplemente archivos que contienen una lista de entradas y los dispositivos se puede acceder mediante la solicitud de E / S en archivos especiales.

2.2. Particiones

Las particiones, son las divisiones lógicas que tienen los dispositivos físicos en los que existe un sistema de archivos. Al más alto nivel, los datos se almacenan en las particiones de los dispositivos físicos. Una partición es una división lógica del medio físico (disco duro, memoria Flash) cuyos datos se organizan según las especificaciones del tipo de partición determinada. Un dispositivo físico puede tener una sola partición que cubre todo el espacio disponible, o puede ser dividido en múltiples particiones para adaptarse a una tarea concreta. Una partición puede pensarse como un disco lógico en el que puede escribirse un sistema de archivos completo.

Linux utiliza una instrucción llamada fdisk para manipular las particiones en dispositivos de bloque. fdisk tiene la capacidad de reconocer la mayoría de los tipos de particiones que pueden encontrarse en las distribuciones de Linux (reconoce más de 90 tipos diferentes de particiones). En la práctica, sólo algunos se utilizan comúnmente en sistemas Linux. Algunos tipos de particiones comunes incluyen Linux, FAT32, y Linux Swap.


Figura 2-1: Relación entre las particiones y los sistemas de archivos.

# fdisk /dev/sdbCommand (m for help): pDisk /dev/sdb: 49 MB, 49349120 bytes4 heads, 32 sectors/track, 753 cylindersUnits = cylinders of 128 * 512 = 65536 bytes Device Boot Start End Blocks Id System/dev/sdb1 * 1 180 11504 83 Linux/dev/sdb2 181 360 11520 83 Linux/dev/sdb3 361 540 11520 83 Linux/dev/sdb4 541 753 13632 83 Linux

Listado 2-1: Salida de la utilidad fdisk cuando se la aplica a un dispositivo CompactFlash, conectado al puerto USB de la PC. Para este caso el subsistema USB asignó el dispositivo al nodo de dispositivo / dev / sdb.

Para este análisis, se han creado cuatro particiones en el dispositivo utilizando la utilidad fdisk. Una de ellas está marcada como “buteable” (o de inicio), como se indica con un asterisco en la columna “Boot”. Esto es simplemente el seteo de una bandera en la estructura de datos que representa la tabla de partición del dispositivo. Como se puede ver en la lista, la unidad lógica de almacenamiento utilizada por fdisk es el cilindro1. En este dispositivo, un cilindro contiene 64KB. Por otra parte, Linux representa la unidad mínima de almacenamiento como un bloque lógico. Puede deducirse que un bloque es una unidad de 1024 bytes. Después la tarjeta CompactFlash se ha dividido de esta manera, cada dispositivo que representa una partición puede estar formateado con un sistema de archivos de su elección. Cuando una partición es formateada con un tipo de sistema de archivos dado, Linux puede montar el sistema de archivo correspondiente de esa partición.

2.3. i-nodos

Un i-nodo, nodo-i o nodo índice es una estructura de datos propia de los sistemas de archivos tradicionalmente empleados en los sistemas operativos tipo UNIX como es el caso de Linux. Un i-nodo contiene las características (permisos, fechas, ubicación, pero NO el nombre) de un archivo regular, directorio, o cualquier otro objeto que pueda contener el sistema de archivos. El término "i-nodo" refiere generalmente a i-nodos en discos (dispositivos en modo bloque) que almacenan archivos regulares, directorios, y enlaces simbólicos. El concepto es particularmente importante para la recuperación de los sistemas de archivos dañados.

Cada i-nodo queda identificado por un número entero, único dentro del sistema de archivos, y los directorios recogen una lista de parejas formadas por un número de i-nodo y nombre identificativo que permite acceder al archivo en cuestión: cada archivo tiene un único i-nodo, pero puede tener más de un nombre en distintos o incluso en el mismo directorio para facilitar su localización.

1 - El término cilindro fue tomado de la unidad de almacenamiento en un medio de rotación. Se compone de los datos de un grupo de cabezas de un sector determinado de un dispositivo de disco. Aquí se utiliza para fines de compatibilidad con las utilidades de sistema de archivo existente.


identificador que el sistema tiene del archivo. Si se quiere ver el i-nodo que representa un archivo basta solo con agregar el modificador -i al comando ls . Existen dos tipos de enlaces: los duros y los simbólicos.

2.5.1. Enlaces duros o hard links

Para crear enlaces entre los archivos se utiliza el comando ln . Para dar un ejemplo, si se quisiera hacer un enlace del archivo “hola” el comando es:

# ln hola saludo

Si ahora hacemos un listado mostrando los i-nodos:

# ls -iltotal 214438 -r-------- 2 root root 64 Apr 29 14:04 hol a14438 -r-------- 2 root root 64 Apr 29 14:04 sal udo

Listado 2-2: Creación de un enlace duro.

Como se ve el número de nombres que los archivos tienen ahora es 2 dado que hemos creado otro nombre que es un enlace al contenido que tenía el archivo hola en el disco. Esto puede verse dado que el primer número del listado, 14438, es el número del i-nodo donde comienza el contenido del archivo hola. Aunque parezca que el contenido se ha duplicado, esto no es así. Ambos archivos apuntan al mismo sitio. Por esto, un archivo no se borra hasta que se haya borrado el último de sus nombres. De esta forma también podemos decir que un directorio no es más que un archivo que contiene información sobre la traslación enlace a i-nodo. También que cada directorio tiene dos enlaces duros en él: . (un enlace apuntando a si mismo) y .. (un enlace apuntando a su directorio padre). En el directorio raíz “/” el enlace “..” siempre apunta a “/.”.

2.5.2. Enlaces simbólicos o symbolic links

A diferencia de los enlaces duros, estos enlaces solo dan otro nombre a un archivo pero no hacen un enlace al nivel de i-nodo. Se puede hacer una comparación con los "Accesos directos" de Windows95. La orden ln -s genera un enlace simbólico.

# ln -s hola saludos# ls -iltotal 214438 -r-------- 1 root root 64 Apr 29 14:04 h ola14446 lrwxrwxrwx 1 root root 4 May 7 08:33 s aludos -> hola#

Listado 2-3: Creación de un enlace simbólico.

Como se ve, el enlace nos muestra a que archivo esta apuntando. Existen diferencias entre este tipo de enlaces y los duros, una de ellas es que ya no están apuntando al mismo i-nodo. Además los bit de permisos aparecen todos encendidos dado que no son usados. Los permisos que se utilizan son los del archivo al que se esta apuntando. Si nos fijamos bien, en la primera posición de los permisos veremos una letra l, esto nos indica que es un enlace simbólico. Otra particularidad es que se pueden crear enlaces simbólicos de archivos que no existen; pero lo mismo no es cierto para los enlaces duros. Con los enlaces simbólicos se puede saber a que archivo están apuntando, no así con los duros. Los enlaces simbólicos son ampliamente usados para las bibliotecas compartidas.


Un descriptor de sistema de archivos ya montado, contiene varios tipos de datos: información que son comunes a todos los tipos de sistema de archivos, punteros a funciones que ofrece el código del núcleo del sistema de archivos físicos, y los datos privados mantenidos por el código de sistema de archivos físicos. Los punteros a función contenidos en dichos descriptores, permiten al VFS el acceso a las rutinas internas del sistema de archivos. Otros dos tipos de descriptores son utilizados por el VFS: un descriptor de i-nodo y un descriptor de archivo abierto. Cada descriptor contiene la información relacionada con los archivos en uso y un conjunto de acciones provistas por el código de sistema de archivos físicos. Aunque el descriptor de i-nodo contiene referencias a las funciones que se pueden utilizar en cualquier archivo (por ejemplo, crear, desvincular), los descriptores de archivo contienen punteros solo a funciones que pueden actuar sobre los archivos abiertos (por ejemplo, leer, escribir).


3. Sistema de archivos ext2

Basándose en el ejemplo del listado 2-1, se tendrá que dar formato a las particiones creadas con fdisk . Para ello, se debe usar la instrucción mke2fs . mke2fs es similar al conocido comando format de DOS. Esta utilidad formatea la partición especificada con el sistema de archivos ext2 (mke2fs es específico para el sistema de archivos ext2); otros sistemas de archivos tienen sus propias versiones de estas instrucciones. Listado 3-1 captura la salida de este proceso.

# mke2fs /dev/sdb1 -L CFlash_Boot_Volmke2fs 1.37 (21-Mar-2005)Filesystem label=CFlash_Boot_VolOS type: LinuxBlock size=1024 (log=0)Fragment size=1024 (log=0)2880 inodes, 11504 blocks575 blocks (5.00%) reserved for the super userFirst data block=1Maximum filesystem blocks=117964802 block groups8192 blocks per group, 8192 fragments per group1440 inodes per groupSuperblock backups stored on blocks: 8193Writing inode tables: doneWriting superblocks and filesystem accounting infor mation: doneThis filesystem will be automatically checked every 39 mounts or180 days, whichever comes first. Use tune2fs -c or -i to override.#

Listado 3-1: Formatear una partición a ext2, usando mke2fs .

El listado 3-1, contiene una gran cantidad de detalles relativos al sistema de archivos ext2 y proporciona una excelente manera de empezar a comprender sus características operativas. Se debe tener en cuenta que esta partición se formatea como de tipo ext2 con una etiqueta de volumen de CFlash_Boot_Vol. Se creó en una partición de Linux (OS Type:) con un tamaño de bloque de 1024 bytes. El espacio se destinó a 2.880 i-nodos, que ocupan 11.504 bloques. Un i-nodo es la estructura de datos fundamental que representa un solo archivo. En cuanto a la salida de mke2fs en el listado 3-1, se puede determinar ciertas características de la organización del dispositivo de almacenamiento. Ya sabemos que el tamaño de bloque es de 1024 bytes. Si es necesario para su aplicación en particular, se le puede especificar al comando mke2fs que formatee un sistema de archivos ext2 con diferentes tamaños de bloque. Las implementaciones actuales permiten tamaños de bloque de 1.024, 2.048 y 4.096 bytes. El tamaño de bloque es siempre un compromiso para un mejor rendimiento. Por un lado, los tamaños de bloque grande dejan más espacio inutilizado en los discos con muchos archivos, ya que cada archivo debe encajar en un número entero de bloques. El fragmento sobrante de cada archivo que no llega a encajar en un número entero de bloques debe ocupar otro bloque completo, así sea un solo byte. Por otra parte, bloques de tamaño muy pequeño aumentan la sobrecarga en el sistema de archivos en el manejo de los meta datos que describen el mapeo “bloque-a-archivo”. La única forma de estar seguro de que se ha elegido el tamaño de bloque correcto es hacer correr una prueba sobre el hardware en que se ha implementado el sistema de archivo.

3.1. Montaje de un sistema de archivo

Una vez creado el sistema de archivos, se lo puede montar el mismo sobre un sistema operativo Linux que esté corriendo, siempre que se tenga acceso a los dispositivos de hardware y que el kernel haya sido compilado con el soporte para el tipo utilizado de sistema de archivos, ya sea como un módulo pre-compilado o uno de carga dinámica. El siguiente comando monta el sistema de archivos creado previamente en el punto de montaje que se le especifica:


# Mount / dev/sdb1 / mnt / flash

En este ejemplo se asume que existe un directorio creado en la máquina Linux, llamado / mnt / flash. Este directorio se llama punto de montaje ya que se instala (monta) la raíz del sistema de archivos, en ese punto de la jerarquía de nuestro sistema residente. Se monta el dispositivo Flash descrito anteriormente, al cuál el Kernel asigna la ubicación / dev/sdb1. En un típico escritorio de Linux, se necesita tener privilegios de root (súper usuario o administrador) para ejecutar este comando2. El punto de montaje, sin importar el lugar que se elija para el mismo, se convierte en el nivel superior (raíz) del dispositivo recién montado. Siguiendo con el ejemplo, para hacer referencia a los archivos del dispositivo Flash, se debe anteponer el camino con / mnt / flash.

El comando mount posee un gran alcance, con muchas variantes. Varias de las opciones que mount acepta dependerán del sistema de archivo y del tipo de operación de montaje. La mayoría de las veces, mount puede determinar el tipo de sistema de archivo con el formato correcto para ser reconocido por el Kernel. El listado 3-2 muestra el contenido de un directorio de un dispositivo flash configurado para un sistema embebido arbitrario.

$ ls -l /mnt/flashtotal 24drwxr-xr-x 2 root root 1024 Jul 18 20:18 bindrwxr-xr-x 2 root root 1024 Jul 18 20:18 bootdrwxr-xr-x 2 root root 1024 Jul 18 20:18 devdrwxr-xr-x 2 root root 1024 Jul 18 20:18 etcdrwxr-xr-x 2 root root 1024 Jul 18 20:18 homedrwxr-xr-x 2 root root 1024 Jul 18 20:18 libdrwx------ 2 root root 12288 Jul 17 13:02 lost+fou nddrwxr-xr-x 2 root root 1024 Jul 18 20:18 procdrwxr-xr-x 2 root root 1024 Jul 18 20:18 rootdrwxr-xr-x 2 root root 1024 Jul 18 20:18 sbindrwxr-xr-x 2 root root 1024 Jul 18 20:18 tmpdrwxr-xr-x 2 root root 1024 Jul 18 20:18 usrdrwxr-xr-x 2 root root 1024 Jul 18 20:18 var$

Listado de 3-2. Listado del dispositivo flash.

El listado de 3-2, es un ejemplo de lo que es la parte superior (raíz) del sistema de archivo de un sistema embebido3.

3.2. Comprobación de la integridad del sistema de a rchivos

El comando e2fsck se utiliza para comprobar la integridad de un sistema de archivos ext2. Un sistema de archivos se puede dañar por varias razones, pero la más común es un fallo de energía inesperado o un apagado intencional cuando los archivos aún no han sido cerrados y los sistemas de archivos no han sido desmontados. Las distribuciones de Linux realizan estas operaciones de manera automática en la secuencia de apagado (suponiendo un cierre ordenado del sistema). Sin embargo, cuando se trata de sistemas integrados, los cortes de energía inesperados son comunes, y se hace necesario tener algunas medidas de defensa contra estos casos. e2fsck es la primera línea de defensa para los sistemas de archivos ext2. El listado 3-3, muestra la salida luego de ejecutar e2fsck en el dispositivo CompactFlash de los ejemplos anteriores. Como fue formateado y correctamente desmontado no presenta errores.

# e2fsck /dev/sdb1e2fsck 1.37 (21-Mar-2005)CFlash_Boot_Vol: clean, 23/2880 files, 483/11504 bl ocks#

Listado de 3-3. Limpieza de las entradas del sistema de archivos.

La instrucción e2fsck chequea varios aspectos del sistema de archivo para comprobar que halla coherencia. Si no se encuentran problemas, se obtiene como salida un mensaje similar al que aparece en

2 Existen sistemas de archivos que pueden ser montados por cualquier usuario, sin necesidad de ser root, este es el caso de los CD-ROM por ejemplo.

3 El Capítulo 6, titulado "Inicialización del sistema", del libro: Embedded Linux Primer;, ofrece orientación y ejemplos de cómo determinar el contenido del sistema de archivos raíz.


el listado 3-3. Se debe tener en cuenta que e2fsck se debe ejecutar sólo sobre un sistema de archivo sin montar. Aunque es posible ejecutarlo en un sistema de archivos montado, el hacerlo puede causar un daño significativo a las estructuras del sistema interno de archivos en el disco o dispositivo Flash. Para crear un ejemplo más interesante, se extrajo el dispositivo de su socket mientras todavía estaba montado; se creó también intencionalmente un archivo y una sesión de edición en el archivo antes de sacarlo del sistema. Esto puede resultar en la corrupción de las estructuras de datos que describen el archivo, así como los bloques de datos reales con los datos del archivo.

# e2fsck -y /dev/sdb1e2fsck 1.37 (21-Mar-2005)/dev/sdb1 was not cleanly unmounted, check forced.Pass 1: Checking inodes, blocks, and sizesInode 13, i_blocks is 16, should be 8. Fix? yesPass 2: Checking directory structurePass 3: Checking directory connectivityPass 4: Checking reference countsPass 5: Checking group summary information/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****/dev/sdb1: 25/2880 files (4.0% non-contiguous), 488 /11504 blocks#

Listado 3-4: Comprobación de un sistema de archivo corrupto.

En el listado 3-4, se puede ver que e2fsck a detectado que la tarjeta CompactFlash no se limpiadesmontada. Además, se puede ver el proceso sobre el sistema de archivos durante la comprobación del e2fsck . El e2fsck hace cinco pasadas sobre el sistema de archivos, controlando diversos elementos de la estructura de datos interna del sistema de archivos. Se puede ver uno de los errores asociado a un archivo está identificado como “i-nodo”4 13, el cuál fue fijado automáticamente porque la bandera -y fue incluida en la línea de instrucción del comando. Debe tenerse en cuenta que, en los problemas que afectan los sistemas de archivos en la vida real, no siempre es fácil encontrar que opción de la instrucción utilizar para repararlo y a veces tampoco es posible reparar ciertos tipos de errores. El diseñador del sistema embebido debe tener en cuenta que si se produjo un fallo en la alimentación impidiendo el normal apagado, el ciclo de arranque posterior al fallo puede demorarse al realizar ciclos análisis del dispositivo de buteo y reparación de errores del sistema. De hecho, si estos errores no se pueden reparar, se detiene el arranque del sistema y se indica que es necesaria la intervención manual. Dependiendo el tamaño del sistema de archivos la comprobación (fsck ) puede durar minutos o incluso horas para los sistemas “multigigabyte”.

Otra defensa contra la corrupción del sistema de archivos es asegurar la escritura inmediata en el disco. La instrucción sync puede ser utilizada para forzar la escritura de todo lo que en la cola de E/S en sus respectivos dispositivos. Una estrategia para minimizar vulnerabilidad a la corrupción de los datos ante una eventual pérdida de energía es la utilización del comando sync luego de que un archivo es escrito o por parte de la aplicaciones de manera estratégica, según lo necesite. El equilibrio aquí es, por supuesto, una penalización en el rendimiento ya que retrasar las escrituras en disco es una estrategia de aumento del rendimiento utilizada en todos los sistemas operativos modernos.

4 Dentro del sistema de archivos ext2 un archivo se lo representa con una estructura llamada “i-nodo”



El ext3 se ha convertido en un sistema de archivos “journaling” (journaling file system o sistema de archivo con registro por diario), poderoso, robusto y de alto rendimiento. Por ello es actualmente el sistema de archivo por defecto para muchas distribuciones de Linux de escritorio, tales como Red Hat y de la serie de Fedora Core. El sistema de archivos ext3 es básicamente una extensión del sistema de archivos ext2 con adición de capacidad de “journaling”.

4.1.Sistemas de archivos con journaling en Linux

Al trabajar con un ordenador, para mejorar el rendimiento de las operaciones de E/S, los datos del disco son temporalmente almacenados en la memoria RAM (Linux utiliza para ello dos mecanismos el page-cache y el buffer-cache). Los problemas surgen si hay un corte de suministro eléctrico antes que los datos modificados en la memoria (dirty buffers) sean grabados nuevamente al disco. Se generaría una inconsistencia en el estado global del sistema de archivos. Por ejemplo, un nuevo archivo que todavía no fue “creado” en el disco u otros que hayan sido borrados pero sus i-nodos y bloques de datos todavía permanecen como “activos” en el disco. El fsck (file system check) fue la herramienta que resolvía dichas inconsistencias, pero el fsck tiene que analizar la partición completa y verificar las interdependencias entre i-nodos, bloques de datos y contenidos de directorios. Con la ampliación de la capacidad de los discos, la recuperación de la consistencia del sistema de archivo se ha convertido en una tarea que requiere mucho tiempo, por lo que crea problemas serios de disponibilidad de las máquinas afectadas. Esta es la razón principal de que los sistemas de archivos hayan importado de las bases de datos las técnicas de transacciones y recuperación, y así hayan aparecido los sistemas de archivos con journaling o registro por diario .

Figura 4-1: Comparativa de los sistemas de archivos con journaling en Linux.

Aclaración: Pb = Petabyte o 1015

bytes; Eb = Exabyte o 1018

bytes.

Un sistema con journaling es un sistema de archivos tolerante a fallos en el cuál la integridad de los


datos está asegurada porque las modificaciones de la meta-información de los archivos son primero grabadas en un registro cronológico (log o journal, que simplemente es una lista de transacciones) antes que los bloques originales sean modificados. En el caso de un fallo del sistema, un sistema con journaling asegura que la consistencia del sistema de archivos es recuperada. El método más común es el de grabar previamente cualquier modificación de la meta-información en un área especial del disco, el sistema realmente grabará los datos una vez que la actualización de los registros haya sido completada. A la hora de recuperar la consistencia después de un fallo, el módulo de recuperación analizará el registro y sólo repetirá las operaciones incompletas en aquellos archivos inconsistentes, es decir que la operación registrada no se haya llevado a cabo finalmente, con lo que se recuperará la consistencia del sistema de archivos casi al instante, ya que en vez de examinar todos los meta-datos (como hace el "fsck"), sólo se inspeccionan aquellas porciones de los meta-datos que han sido cambiadas recientemente. El procedimiento es básicamente el siguiente:

1. Se bloquean las estructuras de datos afectadas por la transacción para que ningún otro proceso pueda modificarlas mientras dura la transacción.

2. Se reserva un recurso para almacenar el journal. Por lo general suelen ser unos bloques de disco, de modo que si el sistema se para de forma abrupta (corte eléctrico, avería, fallo del sistema operativo...) el journal siga disponible una vez reiniciado el sistema.

3. Se efectúan una a una las modificaciones en la estructura de datos. Para cada una:1. Se apunta en el journal como deshacer la modificación y se asegura de que esta información se

escribe físicamente en el disco.2. Se realiza la modificación.

4. Si en cualquier momento se quiere cancelar la transacción se deshacen los cambios uno a uno leyéndolos y borrándolos del journal.

5. Si todo ha ido bien, se borra el journal y se desbloquean las estructuras de datos afectadas.

Las aplicaciones más frecuentes de los sistemas de journaling se usan para implementar transacciones de sistemas de bases de datos y, más recientemente, para evitar la corrupción de las estructuras de datos en las que se basan los sistemas de archivos modernos.

La demanda de sistemas de archivos que soporten terabytes de datos, miles de archivos por directorios y compatibilidad con arquitecturas de 64 bits ha hecho que en los últimos años haya crecido el interés de la disponibilidad de sistemas con journaling en Linux, ya que utilizando estos sistema de archivos se simplifican los reinicios de la máquina, se reduce la fragmentación y se aceleran las operaciones de entrada/salida. Los primeros sistemas de archivos con journaling fueron creados a mediados de los ochenta e incluyen a Veritas (VxFS), Tolerant y JFS de IBM. Linux tiene ahora disponibles cuatro sistemas de archivos transaccionales: ReiserFS de Namesys, XFS de Silicon Graphic s (SGI), JFS de IBM y el ext3 que fue desarrollado por Stephen Tweedie, co-desarrollador del ext2. Cada uno de ellos tiene unas características específicas que le diferencian del resto, alguno se comportan mejor que otros en algunos casos (pero no en todos), por ejemplo ReiserFS es bueno leyendo archivos pequeños o medianos, XFS tiene mejor rendimiento para archivos grandes y con JFS se facilita mucho la migración de sistemas con OS/2 Warp y AIX a Linux.

4.2. Principales características del sistema de arc hivos ext3

El sistema de archivos ext3 es una extensión con journaling del sistema de archivos ext2. Como ya se vio con el journaling se obtiene una enorme reducción en el tiempo necesario para recuperar un sistema de archivos después de una caída, y es por tanto muy recomendable en entornos donde la alta disponibilidad es muy importante, no sólo para reducir el tiempo de recuperación de máquinas independientes sino también para permitir que un sistema de archivos de una máquina caída sea recuperado en otra máquina cuando se tiene un cluster con algún disco compartido. Además se posibilita que el sistema de archivos caído de una máquina (por ejemplo un servidor) esté disponible cuanto antes para el resto de máquinas a través de la red (nfs, samba, ftp, http, etc.).

El principal objetivo del ext3 es por tanto la disponibilidad, es decir, cuando se apague incorrectamente la máquina tener el sistema totalmente disponible al momento después de volver a arrancar sin necesidad de que se tenga que esperar a pasar un fsck , el cual tarda mucho tiempo. Además con ext3 se ha añadido el journaling de manera que sea totalmente compatible con los sistemas de archivos ext2 (es posible migrar sistemas de archivos ext2 existentes a ext3 y viceversa muy fácilmente). Es posible convertir un sistema de archivos ext2 a ext3 sin formatear o volver a escribir todos los datos en


el disco. En el Listado 4-1, se ve como es esto.# mount /dev/sdb1 /mnt/flash <<< Mount the ext2 file system# tune2fs -j /dev/sdb1 <<< Create the jou rnaltune2fs 1.37 (21-Mar-2005)Creating journal inode: doneThis filesystem will be automatically checked every 23 mounts or180 days, whichever comes first. Use tune2fs -c or -i to override.#

Listado de 4-1: Conversión de sistema de archivos ext2 a ext3. Convertir un sistema de archivos de esta forma debe considerarse únicamente como una actividad de desarrollo.

Se debe tener en cuenta que el hecho de montar primero el sistema de archivos en / mnt / flash; es solo a fines ilustrativos; normalmente, se ejecuta este comando en una partición ext2 sin montar. El comportamiento de diseño para tune2fs cuando se monta el sistema de archivos es la creación del archivo diario llamado “.journal”, el cuál es oculto. Los archivos en Linux precedidos por el punto “.” se consideran ocultos, la mayoría de los comandos de Linux simplemente ignoran archivos de este tipo. En el listado de 4-2, podemos ver que el comando ls ha sido invocado con la opción “-al”, que fuerza la aparición en la lista de todos los archivos, sean ocultos o no.

$ ls -al /mnt/flashtotal 1063drwxr-xr-x 15 root root 1024 Aug 25 19:25 .drwxrwxrwx 5 root root 4096 Jul 18 19:49 ..drwxr-xr-x 2 root root 1024 Aug 14 11:27 bindrwxr-xr-x 2 root root 1024 Aug 14 11:27 bootdrwxr-xr-x 2 root root 1024 Aug 14 11:27 devdrwxr-xr-x 2 root root 1024 Aug 14 11:27 etcdrwxr-xr-x 2 root root 1024 Aug 14 11:27 home-rw------- 1 root root 1048576 Aug 25 19:25 .jour naldrwxr-xr-x 2 root root 1024 Aug 14 11:27 libdrwx------ 2 root root 12288 Aug 14 11:27 lost+ founddrwxr-xr-x 2 root root 1024 Aug 14 11:27 procdrwxr-xr-x 2 root root 1024 Aug 14 11:27 rootdrwxr-xr-x 2 root root 1024 Aug 14 11:27 sbindrwxr-xr-x 2 root root 1024 Aug 14 11:27 tmpdrwxr-xr-x 2 root root 1024 Aug 14 11:27 usrdrwxr-xr-x 2 root root 1024 Aug 14 11:27 var

Listado de 4-2. Archivo diario de ext3

Ahora que se creó el archivo diario en el módulo Flash, sea a efectivamente llevado el formato del sistema de archivo a ext3. La próxima vez que se reinicia el sistema o la utilidad e2fsck se ejecuta en la partición que contiene el recién creado sistema de archivos ext3, el archivo de diario automáticamente se hace invisible. Sus meta datos se almacenan en un i-nodo reservado para este propósito. Si bien usted puede ver el archivo “.journal”, tenga en cuenta que es peligroso modificar o borrar este archivo. Es posible y, a veces, ventajoso crear el archivo de diario en un dispositivo diferente. Por ejemplo, si usted tiene más de un dispositivo físico en su sistema, usted puede colocar su sistema de archivos journaling, ext3 en la primera unidad y tener el archivo diario (journal) en la segunda unidad. Este método funciona independientemente de si su almacenamiento físico se basa en Flash o los medios de comunicación de rotación. Para crear el sistema de archivos journaling de un sistema de archivos ext2 existente con el archivo diario en una partición diferente, se debe invocar tune2fs de la siguiente manera:

# Tune2fs dispositivo de J = / dev/sda1-j / dev/sdb 1

Para que esto funcione, se debe ya haber formateado el dispositivo en el que el archivo “journal” va a residir con un sistema de archivos ext3.

Ext3 en realidad es ext2 con un archivo adicional de registro, es decir, es una capa adicionalsobre ext2 que mantiene un archivo de registro log de transacciones. Debido a que está integrado enel ext2 puede que no explote todas las posibilidades de los sistemas de journaling puros, pero seestá trabajando es este área para mejorarlo.


4.3. Integridad de los datos en ext3

Usando ext3 el sistema de archivos puede proporcionar garantías más fuertes respecto a la integridad de los datos en el caso de un apagado incorrecto del sistema. Pudiendo escoger el tipo y nivel de protección que se le da a los datos. Se puede escoger mantener la consistencia de los datos pero permitir daños en los datos dentro del sistema de archivos en el caso de un apagado incorrecto, esto puede dar un pequeño aumento de la velocidad bajo algunas pero no todas las circunstancias. Alternativamente, se puede escoger asegurar que los datos son consistentes con el estado del sistema de archivos, esto significa que nunca habrá "datos basura" de un archivo recientemente escrito después de una caída del sistema. Esta ultima opción es la utilizada por defecto. EL ext3 escribe tres tipos de bloques de datos en el registro:

1. Meta-información: Contiene el bloque de meta-información que está siendo actualizado por la transacción. Cada cambio en el sistema de archivos, por pequeño que sea, es escrito en el registro. Sin embargo es relativamente barato ya que varias operaciones de E/S pueden ser agrupadas en conjuntos más grandes y pueden ser escritas directamente desde el sistema page-cache.

2. Bloques descriptores: Estos bloques describen a otros bloques del registro para que luego puedan ser copiados al sistema principal. Los cambios en estos bloques son siempre escritos antes que los de meta-información.

3. Bloques cabeceras: Describen la cabecera y cola del registro más un número de secuencia para garantizar el orden de escritura durante la recuperación del sistema de archivos.

Con ext3 se mantiene la consistencia tanto en la meta-información (i-nodos o meta datos) como en los datos de los archivos (datos propiamente dichos). A diferencia de los demás sistemas de journaling mencionados anteriormente, la consistencia de los datos también está asegurada.

4.4. Velocidad del sistema de archivos ext3

A pesar de escribir a veces algún dato más de una vez, ext3 es en algunos casos incluso más rápido que el ext2 por que el journaling del ext3 optimiza el movimiento de cabeza del disco duro. Con ext3 se puede escoger entre tres modos de journaling diferentes para optimizar la velocidad, equilibrando esta con una mayor o menor integridad de los datos dependiendo de las necesidades. Los diferentes modos son:

• data=writeback: limita la garantía de integridad de los datos, permitiendo a los antiguos datos aparecer en archivos después de una caída, para un posible pequeño incremento de la velocidad en algunas circunstancias. Este es el modo jouraling por defecto en muchos otros sistemas de archivos journaling, esencialmente proporciona las garantías más limitadas de integridad en los datos y simplemente evita el chequeo en el reinicio del sistema.

• data=ordered (modo por defecto): garantiza que los datos son consistentes con el sistema de archivos. Los archivos escritos recientemente nunca aparecerán con contenidos basura después de una caída.

• data=journal: requiere un "journal" grande para una velocidad razonable en la mayoría de los casos y por lo tanto tarda más tiempo recuperar el sistema en el caso de un apagado incorrecto, pero es algunas veces es más rápido para algunas operaciones ya que funciona muy bien si se escriben muchos datos al mismo tiempo (por ejemplo en los spools de correo o servidores NFS sincronizados). No obstante, utilizar el modo "journal" para un uso normal resulta con frecuencia un poco más lento.

El modo por defecto (ordered) es el recomendable, pudiendo cambiar el modo en el montaje del sistema de archivos.


4.5. Otras ventajas del ext3

Otras ventajas importantes de utilizar ext3 son:

1. El ext3 como el ext2 tiene múltiples desarrolladores y organizaciones involucradas en su desarrollo, por lo que su evolución no depende de una sola persona o empresa.

2. Ext3 proporciona y hace uso de una capa genérica de journaling (Journaling Block Device, JBD) la cual puede ser usada en otros contextos. El ext3 no sólo puede hacer "journal" un sistema de archivos estándar, también otros dispositivos soportados por Linux (NVRAM, disk-on-chip, USB flash memory drives, etc.) pueden ser utilizados con ext3.

3. Ext3 tiene una amplia compatibilidad con todas las plataformas, trabaja tanto en arquitecturas de 32 como de 64 bits, y tanto en sistemas little-endian como big-endian. Algunos sistemas operativos (por ejemplo algunos clones y variantes de UNIX y BeOS) pueden acceder a archivos en un sistema de archivos ext2, estos sistemas también lo pueden hacer en un sistema de archivos ext3.

4. Ext3 no requiere profundos cambios en el corazón del núcleo y no requiere tampoco nuevas llamadas al sistema.

5. Ext3 reserva uno de los i-nodos especiales de ext2 para el registro de journal, pero los datos del mismo pueden estar en cualquier conjunto de bloques, y en cualquier sistema de archivos. Inclusive se puede compartir el registro de journal entre sistemas distintos.

6. El programa de recuperación de sistemas de archivos e2fsck tiene un muy reconocido éxito en la recuperación de datos cuando el software o el hardware falla y corrompe un sistema de archivos. Ext3 usa el mismo código que el “e2fsck” para salvar el sistema de archivos después de una posible corrupción, y por consiguiente tiene la misma robustez que el ext2 contra posibles pérdidas catastróficas de datos cuando haya fallos de corrupción en los mismos.

Todas estas peculiaridades del ext3 son totalmente transparentes al usuario el cual trabajará igual que lo hacía con ext2, incluido el montaje y utilización de otros sistemas de archivos (NFS, dispositivos de almacenamiento externos, etc.).



El ext4 es un sistema de archivos con registro por diario (en inglés Journaling), anunciado el 10 de octubre de 2006 por Andrew Morton, como una mejora compatible de ext3. El 25 de diciembre de 2008 se publicó el kernel Linux 2.6.28, que elimina ya la etiqueta de "experimental" de código de ext4. El ext4 nace para implementar algunas nuevas características que no podían incorporarse al propio ext3. El desarrollo de ext4 ha sido desconocido para la mayoría de usuarios de Linux hasta ahora, que empieza a aparecer por defecto en distribuciones como Fedora, o como opción en distribuciones como ubuntu.

5.1.Mejoras introducidas en el ext4

En la actualidad, ext3 soporta un tamaño máximo de sistema de archivo de 16 TB y 2 TB de tamaño máximo de archivo. Ext4 añade un bloque de direccionamiento de 48-bit, con lo que puede manejar un tamaño máximo de sistema de archivo de un 1 EB5 y 16 TB de tamaño máximo de archivo ¿Por qué 48-bit y no 64-bit? Hay algunas limitaciones que deben ser corregidas antes de hacer que ext4 tenga la plena capacidad con 64 bits. Las estructuras de ext4 datos se han diseñado teniendo esto en mente, por lo que una actualización futura de ext4 implementará completo soporte de 64 bits.

Para que un sistema pueda escribir un archivo en el disco duro, se necesita una metodología y las instrucciones específicas para asignar el espacio. El ext3 usa un esquema de asignación de bloque: Un archivo de 100 MB se asigna como 25600 bloques (cada bloque de 4Kb), cuanto más grande es archivo más bloques requerirá el mapa, cuanto mayor es el tamaño de este mapa, menor es la velocidad con la que puede manejarse. Para solucionar esto, Ext4 introduce el concepto de “Extensiones”. Una extensión es básicamente un grupo de bloques. Con lo que, con un archivo de 100 Mb, por ejemplo, se dice que los datos se escriben en los siguientes “n” bloques; en lugar de dar la información del mapeo de cada bloque por separado. Ext4 soporta hasta 128MB de extensiones, por lo que para un archivo de 1000 MB (o 1 GB), generará un mapa de 10 extensiones en lugar de uno de 256.000 bloques. En última instancia, mejorará el rendimiento y ayudan también a reducir la fragmentación.

Figura 5-1: Extensiones vs. bloques de datos (Izquierda); comparativa de rendimiento (Derecha).

5 1 EB = 1.048.576 TB; 1 EB = 1024 PB; 1 PB = 1024 TB; 1 TB = 1024 GB


El sistema de archivos ext3 es compatible adelante con ext4, siendo posible montar un sistema de archivos ext3 como ext4 y usarlo transparentemente. Del mismo modo ext4 es parcialmente compatible hacia atrás con ext3 ya que puede ser montado como una partición ext3 con la excepción de que si la partición ext4 usa extents, se pierde esta posibilidad. Extents están configurados por defecto desde la versión del kernel 2.6.23. Anteriormente, esta opción requería ser activada explícitamente (por ejemplo mount /dev/sda1 /mnt/point -t ext4dev -o extents).

El sistema de archivos ext4 permite la reserva de espacio en disco para un archivo. La actual metodología consiste en rellenar el archivo en el disco con ceros en el momento de su creación. Esta técnica no es ya necesaria con ext4, ya que una nueva llamada del sistema preallocate() ha sido añadida al kernel Linux para uso de los sistemas de archivos que permitan esta función. El espacio reservado para estos archivos quedará garantizado y es muy probable que sea contiguo. Esta función tiene útiles aplicaciones en streaming y bases de datos.

Ext4 hace uso de una técnica de mejora de rendimiento llamada Allocate-on-flush, también conocida como reserva de memoria retrasada. Consiste en retrasar la reserva de bloques de memoria hasta que la información esté a punto de ser escrita en el disco, a diferencia de otros sistemas de archivos, los cuales reservan los bloques necesarios antes de ese paso. Esto mejora el rendimiento y reduce la fragmentación al mejorar las decisiones de reserva de memoria basada en el tamaño real del archivo.

En ext3 el nivel de profundidad en subdirectorios permitido estaba limitado a 32000. Este límite ha sido aumentado a 64000 en ext4, permitiendo incluso ir más allá de este límite (haciendo uso de "dir_nlink"). Para permitir un rendimiento continuo, dada la posibilidad de directorios mucho más grandes, htree está activado por defecto en ext4. Esta función está implementada desde la versión 2.6.23. htree está también disponible en ext3 cuando la función dir_index está activada.

Ext4 usa checksums en el registro para mejorar la fiabilidad, puesto que los sistemas de archivo journal son de los más utilizados en disco. Esta función tiene un efecto colateral beneficioso: permite de forma segura evitar una lectura/escritura de disco durante el proceso de registro en el journal, mejorando el rendimiento ligeramente.

En ext4, los grupos de bloques no asignados y secciones de la tabla de inodos están marcados como tales. Esto permite a e2fsck saltarlos completamente en los chequeos reduciendo de esta manera el tiempo requerido para chequear un sistema de archivos del tamaño para el que ext4 está preparado.

5.2.Cómo empezar a trabajar con el ext4

Se necesita la herramienta e2fsprogs, actualizada por supuesto, la última versión estable-1.41.3-es recomendable. Por lo menos en las distribuciones debian, incluida la de Ubuntu, la conversión de su sistema de archivos a ext4 cuando se usa un initramfs da como resultado un sistema no buteable, aún cuando se habilita la opción de compatibilidad con ext4. El problema es que la utilidad klibc fstype detecta el sistema de archivos ext4 como ext3, y trata de montarlo como ext3, y falla. La solución es pasar en la línea de comandos del Kernel, la opción rootfstype=ext4 (sin las comillas). Amén de esto el cambio a ext4 es sencillo y hay tres maneras para hacerlo.

5.2.1.Creación de un nuevo sistema de archivo Ext4

Solo se debe actualizar el paquete e2fsprogs a Ext4, y crear el sistema de archivos con mkfs.ext4 .

5.2.2.Migración de sistemas de archivos ext3 a ext4

Se utiliza los comandos tune2fs y fsck del sistema de archivos, luego el sistema de archivo debe se montado nuevamente. Se debe ejecutar:

tune2fs -O extents,uninit_bg,dir_index /dev/yourfil esystem

Luego se debe ejecutar fsck , caso contrario no podrá montarse el sistema de archivos. La ejecución de dicho comando es necesaria para devolver el sistema de archivos a un estado de coherencia. La instrucción pedirá confirmación para realizar una corrección, cada vez que encuentre errores en el checksum de los descriptores de grupo, ya que es probable que ocurran, por lo que se debe “aceptar” para


que sean reconstruidos para poder montar la partición como ext4. Para que no pida confirmación cada vez y la realice en forma automática de agregársele el parámetro “-p”.

fsck -pDf /dev/yourfilesystem

Debe mencionarse también que todos los archivos existentes seguirán utilizando la viejo asignación indirecta para mapear todos los bloques de datos.

5.2.3.Montaje de un sistema ext4 sobre un sistema e xt3

Es posible montar un sistema de archivos ext4, sobre un partición ext3 sin cambiar el formato del disco. Esto significa que se podrá luego volver a montar el sistema ext3 de nuevo. Estro se hace de la siguiente manera:

"mount -t ext4 /dev/yourpartition /mnt"

Hacer esto sin haber hecho el proceso de conversión descrito en la sección anterior obligará a ext4 a no utilizar utilidades para cambiar el formato del disco. O sea que solo se usaran las utilidades de ext4 que no requieran el reformateo del disco, perdiéndose así algunas de las nuevas ventajas; pero con la ventaja de poder volver al formato ext3 en cualquier momento.


6. Sistema de archivos ReiserFS

El sistema de archivos ReiserFS (el cual posee journaling) ha gozado de popularidad entre algunas distribuciones como SuSE y de escritorio como Gentoo. Al igual que el sistema de archivos ext3, ReiserFS garantiza que una determinada operación del sistema de archivos se completará en su totalidad o directamente no se hará; no hay puntos intermedios, eliminando así la posibilidad de que se corrompan los datos. A diferencia de ext3, Reiser4 ha introducido una API para programadores del sistema para garantizar la atomicidad de las operaciones del sistema de archivos. Por ejemplo:

Un programa de base de datos está ocupado en la actualización de registros de la base. Varias órdenes de escritura son expedidas por el sistema de archivos y luego de ejecutar la primer orden se corta la energía, impidiendo que finalicen el resto de pedidos de escritura. Un sistema de archivos journaling garantiza que los cambios en los meta datos han sido almacenados en el archivo de diario (journal file) solo para que cuando la alimentación se reestablezca, el Kernel pueda establecer un punto de coherencia del sistema de archivos. Es decir, si un archivo informó que tenía una longitud de 16KB antes de la falla de energía, será reportado como que tiene 16KB luego de la falla, y la entrada de directorio que representa este archivo (en realidad, el i-nodo) registra correctamente ese tamaño de archivo.

Esto no significa, sin embargo, que los datos se escriben correctamente en el archivo, sino que indica solamente que no hay errores en el sistema de archivos. De hecho, es probable que el programa de base de datos haya perdido en el escenario anterior los datos, lo cuál no es la lógica correcta de una base de datos para recuperar los datos perdidos sino que es necesario que la recuperación ocurra también a nivel de datos dentro de los archivos. Para ello Reiser4 implementa operaciones atómicas de alto rendimiento en su sistema para proteger tanto al estado del sistema de archivos (su coherencia) como a los datos involucrados en las operaciones del sistema de archivos. Proporciona también una API a nivel de usuario para permitir que los programas como los gestores de basa de datos puedan realizar llamados a la instrucción escribir del sistema de archivos, y garantizar la escritura de todo o nada, lo que garantiza no solo coherencia en el sistema de archivos, sino que no hay datos parciales o basura en los archivos sobre los que se operó antes de un fallo.

6.1.Funcionalidades del sistema ReiserFs

• Journaling. Esta es la mejora a la que se ha dado más publicidad, ya que previene el riesgo de corrupción del sistema de archivos.

• Reparticionamiento con el sistema de archivos montado y desmontado. Podemos aumentar el tamaño del sistema de archivos mientras lo tenemos montado y desmontado (online y offline). Para disminuirlo, únicamente se permite estando offline (desmontado). Namesys nos proporciona las herramientas para estas operaciones, e incluso, podemos usarlas bajo un gestor de volúmenes lógicos como LVM o EVMS.

• Tail packing, un esquema para reducir la fragmentación interna.

Figura 6-1: Características del sistema de archivos ReiserFS versiones 3.5 y 3.6.


7. Sistema de archivos JFFS2

Las memoria Flash han sido ampliamente utilizadas en los dispositivos embebidos; debido a la naturaleza de la tecnología Flash, es intrínsecamente menos eficiente y más propensa a la corrupción de los datos provocada por la pérdida de la alimentación ya que tiene tiempos largos de escritura. Esta in-eficiencia se deriva del tamaño de sus bloque, que a menudo suelen ser decenas o centenas de Kilobytes. Además no puede borrarse más de un bloque por vez, aunque el ciclo de escritura puede ser aplicado a un Byte o Palabra por ves.

Para la actualización de un solo archivo, un bloque entero debe ser borrado y reescrito. Es bien sabido que la distribución de tamaños de archivo en cualquier máquina Linux dada (o en otro sistema operativo) contiene una mayoría de archivos pequeños, contra un minoría de archivos grandes.

Figura 7-1: Tamaños de los archivos de un sistema en bytes

El histograma en la Figura 7-1, generado con gnuplot, ilustra la distribución de tamaños de archivo en un sistema Linux típico de desarrollo (número de ocurrencias en el eje y vs. tamaño de archivo en el eje x). Se puede ver que la mayor parte de los tamaños de archivo están por debajo de unos 10KB. El pico en 4096 representa los directorios. Entradas de directorio (también los archivos de sí mismos) son exactamente de 4096 bytes de largo, y hay muchos de ellos. El repunte por encima de 40.000 bytes es un recuento del número de archivos mayores de 40KB aproximadamente, que se ve al final de la cuántica de la medida. Es interesante observar que la gran mayoría de los archivos son muy pequeños. Tamaños de archivos pequeños presentan un desafío único para el diseño de un sistema de archivos para dispositivos Flash, ya que como vimos, el borrado es por bloques enteros y su tamaño suele ser un múltiplo grande del archivo más pequeño, por lo que la Flash está sujeta al tiempo que consume en reescribir un bloque completo.

Supóngase, por ejemplo, que un bloque de Flash de 128KB se utiliza para almacenar 24 archivos de 4096 bytes o menos. Si ahora uno de dichos archivos debe ser modificado, el sistema de archivos de la Flash está obligado a borrar la totalidad el bloque para luego reescribirlo con todos los archivos iguales excepto el que necesitaba modificarse. Este proceso puede llevar un tiempo de procesamiento considerable, (su tiempo de escritura puede llegar a ser mayor que el de un disco rígido), con lo que se agranda la posibilidad de que los datos se corrompan ante un eventual falla de la alimentación. Llegado el caso de que dicha falla ocurre durante la reescritura del bloque de 128KB mencionado, los 24 archivos están en un potencial peligro de perderse. Las cuestiones antes mencionadas y otros problemas han sido reducidos o eliminados por el diseño de la segunda generación del Sistema de archivos de diario Flash JFFS2(Journaling Flash File System 2). El JFFS original fue diseñado por Axis Communications AB de Suecia y se enfocaba específicamente a los dispositivos de memoria Flash comunes en aquel momento. El mismo se basaba en el conocimiento de las arquitecturas de memoria Flash y en las limitaciones que esta presentaba.


Otro problema es que la memoria Flash tiene una vida limitada, en cuanto a ciclos de escritura; los dispositivos típicos se especifican para un mínimo de 100.000 ciclos de escritura, y los más nuevos de 1.000.000 de ciclos. Esta especificación es aplicable a cada bloque del dispositivo Flash. Esta limitación inusual impone la obligación de dividir los ciclos de escritura de manera equitativa entre los bloques de la memoria; JFFS2 utiliza una técnica denominada, de nivelación de desgaste, para llevar a cabo esta función.

La construcción de una imagen JFFS2 es relativamente sencilla. Como siempre, se debe estar seguro que el Kernel tiene soporte para el sistema de archivos JFFS2 y que la estación de trabajo de desarrollo a utilizar contiene una versión compatible del comando mkfs.jffs2 . Imágenes JFFS2 se construyen desde un directorio que contiene los archivos deseados en el archivo imagen del sistema. El listado 7-1, muestra una estructura de directorios típico de un dispositivo flash diseñado para ser utilizado como un sistema de archivos raíz:

$ ls -ltotal 44drwxr-xr-x 2 root root 4096 Aug 14 11:27 bindrwxr-xr-x 2 root root 4096 Aug 14 11:27 devdrwxr-xr-x 2 root root 4096 Aug 14 11:27 etcdrwxr-xr-x 2 root root 4096 Aug 14 11:27 homedrwxr-xr-x 2 root root 4096 Aug 14 11:27 libdrwxr-xr-x 2 root root 4096 Aug 14 11:27 procdrwxr-xr-x 2 root root 4096 Aug 14 11:27 rootdrwxr-xr-x 2 root root 4096 Aug 14 11:27 sbindrwxr-xr-x 2 root root 4096 Aug 14 11:27 tmpdrwxr-xr-x 2 root root 4096 Aug 14 11:27 usrdrwxr-xr-x 2 root root 4096 Aug 14 11:27 var$

Listado de 7-1: Directorio de Diseño para el sistema JFFS2.

Cuando es debidamente cargada con los archivos ejecutables, esta disposición de directorios se pueden utilizar como una plantilla para el comando mkfs.jffs2 . Dicho comando produce el formato adecuado del sistema de archivos JFFS2 para la imagen del árbol de directorios que se muestra en el listado 7-1. Se utilizan parámetros de la línea de comandos para pasarle a mkfs.jffs2 la ubicación del directorio, así como el nombre del archivo de salida para recibir la imagen JFFS2. El valor predeterminado es crear la imagen JFFS2 desde el directorio actual; el listado 7-2, muestra el comandopara la construcción de la imagen JFFS2.

# mkfs.jffs2 -d ./jffs2-image-dir -o jffs2.bin# ls -ltotal 4772-rw-r--r-- 1 root root 1098640 Sep 17 22:03 jf fs2.bindrwxr-xr-x 13 root root 4096 Sep 17 22:02 jf fs2-image-dir#

Listado de 7-2: Ejemplo de uso del comando mkfs.jffs2 .

Para este ejemplo la estructura de directorios y archivos del listado 7.1, se encuentran en el directorio JFFS2-image-dir. Como se ve, se ejecutó arbitrariamente el comando mkfs.jffs2 desde el directorio por encima del sistema de archivos imagen. Con el uso de la bandera “-d”, se le especifica donde se encuentra la plantilla del sistema de archivos. Con la bandera “-o” precedemos el nombre del archivo donde la imagen del JFFS2 será escrita.

Cabe señalar que los sistemas de archivos basados en memorias Flash están sujetos a condiciones que pueden conducir a la destrucción prematura del dispositivo, ya que el mismo está sujeto a un número limitado de ciclos de escritura. Por ejemplo, habilitar logeos de sistema (system loggers: syslogd y klogd) configurados par escribir sus datos en sistemas de archivos basados en dispositivos Flash puede fácilmente hacer que se sobrepase el límite de ciclos de escritura. Algunos tipos de errores de programa pueden dar lugar a ciclos continuos de escritura.


8. Sistema de archivos cramfs

Como se puede ver en el archivo README del proyecto cramfs, el objetivo de cramfs es “meter un sistema de archivos en una pequeña ROM ”. El sistema de archivos cramfs es muy útil para los sistemas integrados que contienen una ROM pequeña o una memoria Flash que posee datos estáticos y programas. Este sistema está diseñado para ser simple, pequeño y comprimir las cosas de manera eficiente. El sistema de archivos cramfs es de sólo lectura, se crea con una utilidad de línea de comandos llamada mkcramfs . Si no se la posee en la estación de trabajo, se la puede descargar de la web. Al igual que con JFFS2, mkcramfs construye una imagen de sistema de archivos de un directorio especificado en la línea de comandos. El listado 8-1, es un detalle del procedimiento para la creación de una imagen cramfs. Se utilizó para este ejemplo, la misma estructura de archivos que para construir la imagen JFFS2, en el listado 7-1 (sección anterior).

# mkcramfsusage: mkcramfs [-h] [-v] [-b blksize] [-e edition] [-i file] [-n name]dirname outfile -h print this help -E make all warnings errors (non-zero exit status) -b blksize use this blocksize, must equal page siz e -e edition set edition number (part of fsid) -i file insert a file image into the filesystem (requires >= 2.4.0) -n name set name of cramfs filesystem -p pad by 512 bytes for boot code -s sort directory entries (old option, ign ored) -v be more verbose -z make explicit holes (requires >= 2.3.39 ) dirname root of the directory tree to be compre ssed outfile output file### mkcramfs . ../cramfs.imagewarning: gids truncated to 8 bits (this may be a se curity concern)# ls -l ../cramfs.image-rw-rw-r-- 1 chris chris 1019904 Sep 19 18:06 ../c ramfs.image

Listado 8-1: Ejemplo de utilización del comando mkcramfs.

El comando mkcramfs se escribió inicialmente sin ningún parámetro reproducir el mensaje de modos de uso, ya que no hay ninguna página de manual para esta utilidad y esta es la mejor manera de comprender su utilización. Paso seguido se reescribió el comando con el directorio actual como primer parámetro “ . “, indicando de esta manera que es la fuente para el sistema de archivos cramfs; luego como segundo parámetro se colocó un archivo llamado “cramfs.image” con lo que se indicó que es el archivo destino. Por último se enumeran los archivos recién creados y vemos un nuevo archivo llamado “cramfs.image”. Se debe tener en cuenta que si el kernel está configurado para soportar el sistema cramfs, se puede montar la imagen de este sistema de archivos en la estación de trabajo de desarrollo de Linux y examinar su contenido. Ahora bien, como es un sistema de archivos de solo lectura, no podrá ser modificado. El listado 8-2, muestra el montaje del sistema de archivos cramfs en el punto de montaje llamado / mnt / flash.

# mount -o loop cramfs.image /mnt/flash# ls -l /mnt/flashtotal 6drwxr-xr-x 1 root root 704 Dec 31 1969 bindrwxr-xr-x 1 root root 0 Dec 31 1969 devdrwxr-xr-x 1 root root 416 Dec 31 1969 etcdrwxr-xr-x 1 root root 0 Dec 31 1969 homedrwxr-xr-x 1 root root 172 Dec 31 1969 libdrwxr-xr-x 1 root root 0 Dec 31 1969 procdrws------ 1 root root 0 Dec 31 1969 rootdrwxr-xr-x 1 root root 272 Dec 31 1969 sbindrwxrwxrwt 1 root root 0 Dec 31 1969 tmp


drwxr-xr-x 1 root root 124 Dec 31 1969 usrdrwxr-xr-x 1 root root 212 Dec 31 1969 var#

Listado 8-2: Examen del sistema de archivos cramfs.

Nótese el mensaje de advertencia en relación con el ID de grupo (GID), cuando el comando mkcramfs fue ejecutado (Listado 8-1). El sistema de archivos cramfs utiliza meta datos muy concisos para reducir el tamaño del archivo de sistema y aumentar la velocidad de ejecución. Una de las “características” del sistema de archivos cramfs, es que se trunca el campo del ID de grupo a 8 bits. Linux utiliza un campo de 16-bits para el ID de grupo. El resultado es que los archivos creados con un ID de grupo mayor que 255 se truncan presentando en pantalla la advertencia que puede verse en el listado 8-1. Aunque un poco limitado en términos de tamaño máximo de archivo, número máximo de archivos, y así sucesivamente, el sistema de archivos cramfs es ideal para la ROM de arranque, en el que la operación de sólo lectura y la compresión rápida son necesarias.


9. Sistema de archivos de red

El sistema de archivos de red o NFS (de sus siglas en inglés: Network File System) es propio del entorno UNIX. Configurado correctamente, el NFS permite exportar un directorio de un servidor NFS y montarlo en un equipo cliente remoto como si se tratara de un sistema de archivos local. Esto es útil generalmente en las grandes redes de máquinas UNIX / Linux, y puede ser una panacea para los desarrolladores de sistemas embebidos. Usando NFS en su diseño un diseñador de sistemas embebidos puede tener acceso a un gran número de archivos, bibliotecas, herramientas y utilidades durante el desarrollo y la depuración, incluso si el sistema embebido objeto de su diseño es de recursos limitados.

Al igual que con los anteriores sistemas de archivos, el kernel debe estar configurado con el soporte de NFS, tanto para la funcionalidad del lado servidor como para la del lado del cliente. Las funciones de servidor y cliente NFS se configuran de forma independiente en la configuración del kernel.Si bien las Instrucciones detalladas para configurar y ajustar el NFS están fuera del alcance de esta monografía, una breve introducción servirá de ayuda para ilustrar la utilidad que un NFS puede tener en el ambiente de los sistemas embebidos.

En una estación de trabajo de desarrollo con el NFS habilitado, un archivo contiene los nombres de cada directorio que desea exportar a través del sistema de archivos de red. En Red Hat y otras distribuciones, este archivo se encuentra ubicado en el directorio / etc y se lo llama “exports”. El listado 9-1, muestra un ejemplo de como / etc / exports puede ser encontrado en una estación de trabajo de desarrollo utilizada para el desarrollo de sistemas embebidos.

$ cat /etc/exports# /etc/exports/home/chris/sandbox/coyote-target *(rw,sync,no_root _squash)/home/chris/workspace *(rw,sync,no_root_squash)$

Listado 9-1: Contenido de / etc / exports

Este archivo contiene los nombres de dos directorios en una estación de trabajo de desarrollo de Linux. El primer directorio contiene el sistema de archivo de destino para placa de referencia ADI Engineering Coyote. El segundo directorio es un área de trabajo general que contiene proyectos específicos para un sistema embebido. Esto es arbitrario, ya que se pueden poner las cosas en cualquier manera que se elija. En un sistema integrado con NFS habilitado, el siguiente comando monta el directorio “.../workspace” exportado por el servidor NFS en el punto de montaje que se elija:

$ mount -t nfs pluto:/home/chris/workspace /workspa ce

Algunos puntos importantes sobre este comando son: Estamos instruyendo al comando mount para montar de un directorio remoto (en un equipo llamado Pluto) en un punto de montaje local llamado /workspace. Se deben cumplir dos requisitos en el sistema embebido destino, por trabajar con esta sintaxis. En primer lugar, para que la placa destino pueda reconocer el nombre simbólico de la máquina llamada Pluto, esta debe ser capaz de resolver el nombre simbólico. La manera más sencilla de hacer esto es colocar una entrada en el archivo / etc / hosts en la placa destino. Esto permite que el subsistema de red pueda resolver el nombre simbólico y transformarlo en su dirección IP correspondiente. La entrada en el archivo / etc / hosts de la placa destino tendría este aspecto:

192.168.10.9 Pluto

El segundo requisito es que el sistema embebido destino debe tener un directorio en el directorio raíz llamado /workspace; este será el punto de montaje. El comando mount anterior causa que el contenido del directorio /home /chris /workspace del servidor NFS, esté disponible en el sistema embebido en la ruta /workspace. Esto es bastante útil, sobre todo en un entorno cruzado de desarrollo. Digamos que un grupo está trabajando en un gran proyecto sobre un dispositivo embebido. Cada vez que se realicen cambios en el proyecto, es necesario mover la aplicación al dispositivo para que se pueda probar y depurar. Usando el NFS en la manera que se a descrito, y asumiendo que en el host se está trabajando en el directorio NFS exportado, los cambios estarán disponibles de inmediato en el sistema embebido destino sin necesidad de cargar nuevamente los archivos del proyecto compilado. Esto puede acelerar considerablemente el desarrollo.


9.1.Sistema de archivos raíz en NFS

Montando el área de trabajo del proyecto en el dispositivo destino es muy útil para el desarrollo y la depuración (aún a nivel de código fuente), ya que facilita el acceso rápido a los cambios y al código fuente. Esto es especialmente útil cuando el sistema de destino está severamente restringido en sus recursos. El NFS realmente se destaca como una herramienta de desarrollo al permitir montar el sistema de archivo raíz del dispositivo embebido destino enteramente desde un servidor NFS. El listado 9-1, muestra la entrada coyote-target. Este directorio en la estación de trabajo de desarrollo podría contener cientos o miles de archivos compatibles con la arquitectura del dispositivo embebido sobre el que se está realizando el diseño. Las principales distribuciones de Linux embebido dirigidas a los sistemas integrados de buques, poseían decenas de miles de archivos compilados y probados para la arquitectura destino elegida. Para ilustrar esto, el listado 9-2 contiene una lista de directorios del directorio coyote-target al que se hace referencia en el listado 9-1.

$ du -h --max-depth=1724M ./usr4.0K ./opt39M ./lib12K ./dev27M ./var4.0K ./tmp3.6M ./boot4.0K ./workspace1.8M ./etc4.0K ./home4.0K ./mnt8.0K ./root29M ./bin32M ./sbin4.0K ./proc64K ./share855M .$$ find -type f | wc -l29430

Listado de 9-2: Ejemplo de resumen de sistema de archivo destino.

Figura 9-1: Configuración del kernel NFS


Este sistema de archivos destino contiene poco menos de un gigabyte de archivos binarios destinados a la arquitectura ARM. Como se puede ver de la lista, esto es más de 29.000 archivos binarios de configuración y documentación. Esto difícilmente cabría en una memoria Flash de un sistema embebido y esta es la potencialidad del montaje de raíz del NFS. Para fines de desarrollo, se puede aumentar mucho la productividad si el sistema embebido se carga con todas las herramienta y utilidades con que se está familiarizado en una estación de trabajo Linux. De hecho, probablemente decenas de herramientas de línea de comandos y utilidades de desarrollo que se poseen pero no se suelen ver pueden ayudar a ahorrar tiempo de desarrollo.

Habilitar el sistema embebido para montar el sistema de archivos raíz a través de NFS en tiempo de arranque es relativamente sencillo. En primer lugar, se debe configurar el Kernel del dispositivo objetivo para que soporte NFS. También hay una opción de configuración para permitir el montaje del sistema de archivos raíz desde un directorio NFS remoto. Esto se ilustra en la Figura 9-1. El soporte para el sistema de archivos NFS ha sido seleccionado, junto con el soporte para sistemas de archivos raíz en NFS. Después de que estos parámetros de configuración del kernel han sido seleccionados, todo lo que queda es alimentar de alguna manera al Kernel de la información necesaria para que sepa dónde buscar el servidor NFS. Para esto hay varios métodos que se pueden utilizar, y algunos dependen de la arquitectura del dispositivo de destino elegida y de la elección del gestor de arranque. Como mínimo, al núcleo se le pueden pasar los parámetros apropiados en la línea de comandos del kernel para configurar el IP del puerto y la información sobre el encendido del servidor. Una típica línea de comandos del kernel puede tener este aspecto:

console=ttyS0,115200 ip=bootp root=/dev/nfs

Esto le indica al Kernel que debe esperar un sistema de archivos raíz a través de NFS y debe obtener los parámetros pertinentes (nombre del servidor, dirección IP del servidor, y directorio raíz para el montaje) de un servidor BOOTP. Esta es una de las configuraciones más comunes y de gran utilidad durante la fase de desarrollo de un proyecto. Si la configuración de la dirección IP del dispositivo objetivo es estática, la línea de comandos del Kernel puede verse de la siguiente manera:

console=ttyS0,115200 \ip=192.168.1.139:192.168.1.1:192.168.1.1:255.255.25 5.0:coyote1:eth0:off \ nfsroot=192.168.1.1:/home/chris/sandbox/coyote-t arget \ root=/dev/nfs

Por supuesto, todo esto sería en una línea. El parámetro IP se define en .../net/ipv4/ipconfig.c ; y tiene la siguiente sintaxis (todos en una sola línea):

ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostn ame>:<device>:<PROTO>

Aquí, el IP del cliente es la dirección IP del dispositivo embebido; el IP del servidor es la dirección del servidor NFS; el IP del gateway (gw-ip) es la puerta de enlace (router) en caso de que el IP del servidor esté en una subred diferente del IP del dispositivo; la máscara de red define la clase de direccionamiento IP. El hostname es una cadena de caracteres que se le pasa como el nombre del host de destino; device es el nombre del dispositivo Linux, tal como “eth0”; y PROTO, define el protocolo usado para obtener los parámetros iniciales de IP.


10. Pseudo sistemas de archivos

Un número de sistemas de archivos entran en la categoría de los Pseudo Sistemas de archivos en el menú de configuración del Kernel. Juntos, proporcionan una gran variedad de servicios útiles en una amplia gama de aplicaciones.

10.1. Pseudo sistema de archivos proc

El sistema de archivos proc tomó su nombre de su propósito original, una interfaz que permite al Kernel comunicar la información sobre cada proceso que se encuentra corriendo en un sistema Linux. En el transcurso del tiempo, ha crecido y madurado para ofrecer mucho más que procesar la información de los procesos. El sistema de archivos proc se ha convertido en una necesidad virtual para todos, aún para los más sencillos sistemas Linux, incluso los integrados. Muchas funciones a nivel de usuario se basan en el contenido del sistema de archivos / proc para hacer su trabajo. Por ejemplo, el comando mount, ejecutado sin ningún parámetro, enumera todos los puntos de montaje actualmente activos del sistema que está corriendo, a partir de la información entregada por / proc / mounts. Si el archivo / proc , del sistema no está disponible, el comando mount retorna sin resultados. El listado 10-1, ilustra esto en la placa ADI Engineering Coyote.

# mountrootfs on / type rootfs (rw)/dev/root on / type nfs(rw,v2,rsize=4096,wsize=4096,hard,udp,nolock,addr=1 92.168.1.19)tmpfs on /dev/shm type tmpfs (rw)/proc on /proc type proc (rw,nodiratime)< Now unmount proc and try again ...># umount /proc# mount#

Listado 10-1: Dependencia de montaje en / proc.

Puede verse que en el listado 10-1, / proc sí aparece como un sistema de archivos montado, del tipo proc, montado en / proc. Esto no es un doble discurso, ya que el sistema debe tener un punto de montaje de nombre / proc en el nivel superior del árbol de directorios como destino para que el sistema de archivos proc sea montado.6Para montar el archivo / proc, el sistema utiliza el comando mount como con cualquier otro sistema de archivos:

$ mount -t proc /proc /proc

La forma general del comando mount, como se describe en el manual es: mount [-t fstype] something somewhere. En la invocación anterior, se podría haber sustituido / proc por none, como sigue:

$ mount -t proc none /proc

El parámetro something no es estrictamente necesario porque proc es un pseudo sistema de archivos y no un dispositivo físico real. Sin embargo, es de ayuda especificar / proc, como en el ejemplo anterior, para recordar que se está montando el sistema de archivos proc en el directorio / proc (o, más apropiadamente, en el punto de montaje / proc). Cave aclarar que para obtener la funcionalidad del sistema de archivos proc, debe habilitarse su soporte en la configuración del Kernel. Esta opción de configuración del kernel se puede encontrar en el submenú de los sistemas de archivos en la categoría de pseudo sistemas de archivos.

Cada proceso de usuario que ejecuta el Kernel está representado por una entrada en el sistema de archivos / proc. Por ejemplo, el proceso init al que se le asigna siempre el identificador de proceso (PID) número 1, estará representado por un directorio / proc / 1. Es decir que los procesos en el sistema de

6 Ciertamente, es posible montar / proc donde a uno le parezca en su sistema de archivos, pero todas las utilidades (incluido mount ) que requieren proc, esperan encontrarlo montado en / proc.


archivos proc son representados por un directorio cuyo nombre es su número de PID. El listado 10-2, muestra el contenido de este directorio en el sistema embebido “Coyote”.

# ls -l /proc/1total 0-r-------- 1 root root 0 Jan 1 00:25 auxv-r--r--r-- 1 root root 0 Jan 1 00:21 cmdlinelrwxrwxrwx 1 root root 0 Jan 1 00:25 cwd -> /-r-------- 1 root root 0 Jan 1 00:25 environlrwxrwxrwx 1 root root 0 Jan 1 00:25 exe -> /sbin/initdr-x------ 2 root root 0 Jan 1 00:25 fd-r--r--r-- 1 root root 0 Jan 1 00:25 maps-rw------- 1 root root 0 Jan 1 00:25 mem-r--r--r-- 1 root root 0 Jan 1 00:25 mounts-rw-r--r-- 1 root root 0 Jan 1 00:25 oom_adj-r--r--r-- 1 root root 0 Jan 1 00:25 oom_sco relrwxrwxrwx 1 root root 0 Jan 1 00:25 root -> /-r--r--r-- 1 root root 0 Jan 1 00:21 stat-r--r--r-- 1 root root 0 Jan 1 00:25 statm-r--r--r-- 1 root root 0 Jan 1 00:21 statusdr-xr-xr-x 3 root root 0 Jan 1 00:25 task-r--r--r-- 1 root root 0 Jan 1 00:25 wchan

Listado 10-2: proceso init, entradas / proc.

Estas entradas, que están presentes en el sistema de archivos / proc para cada proceso en ejecución, contienen mucha información útil, especialmente para el análisis y depuración de un proceso. Por ejemplo, la entrada cmdline contiene la línea de comandos completa que se utiliza para invocar el proceso, incluidos los argumentos. Los directorios cwd y root contienen la vista de los procesos del directorio de trabajo actual y del directorio raíz actual. Una de las entradas más útil para la depuración del sistema es la entrada maps. Esta contiene una lista de cada uno de segmento de memoria virtual asignados al programa, junto con los atributos de cada uno. El listado 10-3 es la salida de / proc/1/maps en el ejemplo visto del proceso init.

# cat /proc/1/maps00008000-0000f000 r-xp 00000000 00:0a 9537567 /s bin/init00016000-00017000 rw-p 00006000 00:0a 9537567 /s bin/init00017000-0001b000 rwxp 00017000 00:00 040000000-40017000 r-xp 00000000 00:0a 9537183 /l ib/ld-2.3.2.so40017000-40018000 rw-p 40017000 00:00 04001f000-40020000 rw-p 00017000 00:0a 9537183 /l ib/ld-2.3.2.so40020000-40141000 r-xp 00000000 00:0a 9537518 /l ib/libc-2.3.2.so40141000-40148000 ---p 00121000 00:0a 9537518 /l ib/libc-2.3.2.so40148000-4014d000 rw-p 00120000 00:0a 9537518 /l ib/libc-2.3.2.so4014d000-4014f000 rw-p 4014d000 00:00 0befeb000-bf000000 rwxp befeb000 00:00 0#

Listado 10-3: Segmentos de memoria del proceso init desde / proc.

La utilidad de esta información es evidente. Se puede ver los segmentos de programa del proceso init en las primeras dos entradas. También se puede ver los segmentos de memoria utilizados por las bibliotecas de objetos, compartidas por el proceso init. El formato es el siguiente:

vmstart-vmend attr pgoffset devname inode filenam e

Aquí, vmstart y vmend son el inicio y finalización respectivamente, de direcciones de memoria virtual; attr indica los atributos de la región de memoria, tales como leer, escribir y ejecutar, y le dice que esta región es compartida; pgoffset es el offset en la página de la región (un parámetro del núcleo de memoria virtual), y devname, mostrada como xx:xx, es una representación del núcleo, de la ID del dispositivo asociado a esta región de memoria. Las regiones de memoria que no están asociadas con un archivo tampoco se asocian a un dispositivo, y se ven como 00:00. Las dos últimas entradas son los i-nodos y archivos asociados con la región de memoria dada. Por supuesto, si no hay ningún archivo, no hay


ningún i-nodo asociado a él, y se muestra con un cero. Estos son, por lo general, los segmentos de datos. Otras entradas útiles se enumeran para cada proceso. La entrada status contiene información del

estado del proceso en ejecución, incluyendo elementos como el PID del padre, los IDs de usuario y de grupo, estadísticas del uso de la memoria virtual, señales y capacidades. Algunas entradas / proc de uso frecuente son cpuinfo, meminfo, y version. Las listas de entrada cpuinfo proporcionan los atributos del procesador/es, sobre el que está funcionando el sistema. La entrada meminfo proporciona estadísticas sobre toda la memoria del sistema. La entrada version es un espejo de la cadena versión del kernel de Linux, junto con la información con que el compilador y la máquina utilizaron para construir el Kernel.

Estas y otras entradas / proc, mucho más útiles son provistas por el Kernel, lo antes mencionado solo es la parte más superficial de este útil subsistema. Muchas utilidades se han diseñado para la extracción y presentación de la información contenida en el sistema de archivos proc. Dos ejemplos populares son los comandos top y ps , con los que cada diseñador de sistemas embebidos debería estar íntimamente familiarizado. Otros comandos útiles para la interfaz con el sistema de archivos proc son free , pkill , pmap , y uptime . Ver el paquete de procps para obtener más detalles.

10.2. Pseudo sistema de archivos sysfs

Así como el sistema de archivos proc, sysfs no es representativo de un dispositivo físico real. En cambio, sysfs, modela objetos específicos del Kernel , tales como los dispositivos físicos y proporciona una manera de asociar a los dispositivos con sus respectivos controladores. Algunos agentes en una distribución típica de Linux dependerán de la información en sysfs. Es posible hacerse una idea de que tipo de objetos se exportan mirando directamente en el directorio de estructuras exportadas por sysfs. El listado 10-4, muestrea el nivel superior del directorio /sys de la placa Coyote utilizada anteriormente en otros ejemplos.

# dir /systotal 0drwxr-xr-x 21 root root 0 Jan 1 00:00 bloc kdrwxr-xr-x 6 root root 0 Jan 1 00:00 busdrwxr-xr-x 10 root root 0 Jan 1 00:00 clas sdrwxr-xr-x 5 root root 0 Jan 1 00:00 devi cesdrwxr-xr-x 2 root root 0 Jan 1 00:00 firm waredrwxr-xr-x 2 root root 0 Jan 1 00:00 kern eldrwxr-xr-x 5 root root 0 Jan 1 00:00 modu ledrwxr-xr-x 2 root root 0 Jan 1 00:00 powe r#

Listado de 10-4: Contenido del nivel superior del directorio / sys.

Como se puede ver, sysfs proporciona un subdirectorio para cada clase importante de dispositivo del sistema, incluyendo los buses del sistema. Por ejemplo, en el subdirectorio “block”, cada dispositivo de bloque es representado por una entrada del subdirectorio. Lo mismo vale para el resto de directorios en el nivel superior. La mayoría de la información almacenada por sysfs está en un formato adecuado para que sea entendible. Por ejemplo, para descubrir los dispositivos en el bus PCI, se puede mirar directamente en el subdirectorio / sys / bus / pci. En el dispositivo embebido Coyote, antes mencionado, el cuál tiene un solo dispositivo PCI integrado (Tarjeta de Ethernet), el directorio tiene este aspecto:

# ls /sys/bus/pci/devices/0000:00:0f.0 -> ../../../devices/pci0000:00/0000:00 :0f.0

Esta entrada es en realidad un enlace simbólico que apunta a otro nodo del árbol de directorios sysfs. Se ha formateado aquí la salida de ls aquí para ilustrar esto, mientras que todavía cabe en una sola línea. El nombre del enlace simbólico es la representación del núcleo del bus PCI, y apunta a un subdirectorio del directorio devices llamado pci0000: 00 (la representación del bus PCI), que contiene un número de subdirectorios y archivos que representan los atributos de este dispositivo PCI específico. Ver la información de esta manera no resulta sencillo. Existe un comando útil para navegar por la estructura de directorios del sistema de archivos sysfs, llamado systool , se trata del paquete sysfsutils que se encuentra en sourceforge.net. Si se utiliza systool para ver el bus PCI de la discusión anterior, se obtendrá la siguiente salida:


$ systool -b pci Bus = "pci" 0000:00:0f.0 8086:1229

Nuevamente puede verse como el Kernel representa el bus y el dispositivo (0F), pero esta vez la herramienta muestra el ID de los fabricantes (8086 = Intel) y el ID de dispositivo (1229 = eepro100 tarjeta Ethernet) obtenidos a partir del subdirectorio /sys/devices/pci0000:00 de / sys donde se guardan estos atributos. Ejecutado sin parámetros, systool muestra la parte superior de la jerarquía del sistema. El listado 10-5, es un ejemplo realizado sobre la placa Coyote.

$ systoolSupported sysfs buses: i2c ide pci platformSupported sysfs classes: block i2c-adapter i2c-dev input mem misc net pci_bus ttySupported sysfs devices: pci0000:00 platform system

Listado 10-5: Salida del comando systool.

Se puede ver en esta lista la variedad de información de sistema disponible desde sysfs. Muchas instrucciones utilizan esta información para determinar las características de los dispositivos del sistema o para hacer cumplir las políticas del sistema, tales como la gestión de energía y capacidad de conexión en caliente.


11. Otros sistemas de archivos

Numerosos sistemas de archivos son compatibles con Linux, pero la cobertura de todos ello escapa al alcance de la presente monografía. Sin embargo, es necesario estar enterado de algunos sistemas de archivos importantes que con frecuencia aparecen en los sistemas embebidos.

El sistema de archivos “ramfs” es considerado el mejor desde el contexto del módulo de código fuente de Linux que se implemente. El listado 11-1, reproduce los comentarios del código furnte del sistema de archivos ramfs.

/* * Resizable simple ram filesystem for Linux. * * Copyright (C) 2000 Linus Torvalds. * 2000 Transmeta Corp. * * Usage limits added by David Gibson, Linuxcare Au stralia. * This file is released under the GPL. *//* * NOTE! This filesystem is probably most useful * not as a real filesystem, but as an example of * how virtual filesystems can be written. * * It doesn't get much simpler than this. Consider * that this file implements the full semantics of * a POSIX-compliant read-write filesystem.

Listado de 9-19. Linux ramfs, Comentarios del código fuente.

Este módulo fue escrito principalmente como un ejemplo de cómo los sistemas de archivos virtuales pueden ser escritos. Una de las principales diferencias entre este sistema de archivos y el disco ram de instalación que se encuentra en los Kernels Linux modernos es su capacidad para reducir o aumentar su tamaño de acuerdo a su uso. Un disco de ram no tiene esta propiedad.

El sistema de archivos “tmpfs” es similar al “ramfs”. En ambos sistemas todo se almacena en la memoria virtual del núcleo, y el contenido de tmpfs se pierde en el apagado o reinicio. El archivo tmpfs del sistema es útil para el rápido almacenamiento temporal de archivos. Se puede usar tmpfs montado en / tmp en una aplicación de MIDI / audio, para acelerar la creación y supresión de los objetos temporales requeridos por el subsistema de audio. Esta es también una buena forma de mantener el directorio / tmp limpio ya que el contenido se pierde en cada reinicio del sistema. El montaje de tmpfs es similar al de cualquier otro sistema de archivos virtual:

# mount -t tmpfs /tmpfs /tmp

Como ocurre con otros sistemas de archivos virtuales tales como / proc, el primer parámetro es /tmpfs, pero podría ser la palabra none y seguir funcionando. Sin embargo, es una buena práctica escribir tmpfs para recordar el sistema de archivos virtual que se está montando.


12. Construcción de un sistema de archivos simple

En esta sección se demuestra el uso de la utilidad loopback device del Kernel Linux. Esta utilidad permite que un archivo pueda usarse como un bloque de un dispositivo. En definitiva, se puede construir una imagen de un sistema de archivos en un archivo normal y utilizar loopback device para montarlo de la misma manera que se monta un dispositivo. Para construir un simple sistema de archivos raíz, se debe comenzar creando un archivo de tamaño fijo que contenga solo ceros:

# dd if=/dev/zero of=./my-new-fs-image bs=1k count= 512

Este comando crea un archivo de 512 KB que contiene sólo ceros. Llenamos el archivo con ceros para ayudar a la posterior compresión y tener un patrón coherente de datos para inicializar los bloques de datos dentro del sistema de archivos. Debe tenerse cuidado con el comando dd , la ejecución de dd sin límite (cuenta =) o con un límite inadecuado puede llenar el disco duro y posiblemente dañar el sistema. El comando dd es una herramienta de gran alcance y debe usarse con el debido cuidado. Errores simples de tipeo en comandos como dd , ejecutado como root, han provocado la destrucción de innumerables sistemas de archivos. Una vez obtenido el nuevo archivo imagen, se actualiza el formato de archivo para que contenga las estructuras de datos definidas por un sistema de archivo dado. En este ejemplo, se construirá un sistema de archivos ext2. En el listado 12-1, pueden verse los detalles del procedimiento.

# /sbin/mke2fs ./my-new-fs-imagemke2fs 1.35 (28-Feb-2004)./my-new-fs-image is not a block special device.Proceed anyway? (y,n) yFilesystem label=OS type: LinuxBlock size=1024 (log=0)Fragment size=1024 (log=0)64 inodes, 512 blocks25 blocks (4.88%) reserved for the super userFirst data block=11 block group8192 blocks per group, 8192 fragments per group64 inodes per groupWriting inode tables: doneWriting superblocks and filesystem accounting infor mation: doneThis filesystem will be automatically checked every 24 mounts or180 days, whichever comes first. Use tune2fs -c or -i to override.#

Listado 12-1: Creación de una imagen de sistema de archivos ext2.

Al igual que con dd , el comando mke2fs puede destruir su sistema, por lo que debe utilizarse con cuidado. En este ejemplo, mke2fs se utilizó para dar formato a un archivo en lugar de a una partición de disco duro (dispositivo de bloque) como está previsto. Por lo que mke2fs, detectado este hecho pidió que se confirme la operación. Después de confirmar, mke2fs procedió a escribir un superbloque ext2 y estructuras de datos del sistema de archivos en el archivo. A continuación, se puede montar este archivo como cualquier dispositivo, utilizando el comando loopback device :

# mount -o loop ./my-new-fs-image /mnt/flash

Este comando monta el archivo ./my-new-fs-image como un sistema de archivos en el punto de montaje llamado / mnt / flash. El nombre del punto de montaje no es importante, se puede montar en cualquier lugar, siempre y cuando el punto de montaje exista. Se puede usar mkdir para crear el punto de montaje.

Después de que el archivo imagen del sistema de archivos recientemente creado se monta como un sistema de archivos, se es libre para realizar cambios en él. Se puede agregar y borrar directorios, crear nodos de dispositivos, y así sucesivamente. Se puede usar tar para copiar archivos dentro o fuera del sistema. Cuando los cambios se han completado, se guardan en el archivo, suponiendo que no exceda el tamaño del dispositivo. Recordar que con este método, el tamaño se fija en el momento de la creación y no puede ser cambiado.


13. Bibliografía y Agradecimientos

13.1.Bibliografía

1. “Journal File System in Linux”. Ricardo Galli. 2001.2. “Journaling the Linux ext2 Filesystem”. Sthephen C. Tweedie. 1998.3. “Ext3, Journaling Filesystem”. Stephen C. Tweedie. 2000.4. “Whitepaper: Red Hat's New Journaling File System: ext3”. Michael K. Johnson. Red Hat Inc. 2001.5. “Red Hat Linux/x86 7.2 Release Notes”. Red Hat Inc. 2001.6. “Advanced filesystem implementor's guide”. (IBM DeveloperWorks). Daniel Robbins. 2001.7. “Journaling File Systems”. (Linux Magazine). Steve Best. 2002.8. “Linux Filesystems”. William von Hagen. 2002.9. [Accetta et al. 1986] M. Accetta, R. Baron, W. Bolosky, D. Golub, R. Rashid, A. Tevanian, and M. Young. Mach: A New Kernel Foundation For UNIX Development. In Proceedings of the USENIX 1986 Summer Conference , June 1986.10. [Bach 1986] M. Bach. The Design of the UNIX Operating System . Prentice Hall, 1986.11. [Bina and Emrath 1989] E. Bina and P. Emrath. A Faster fsck for BSD Unix. In Proceedings of the USENIX Winter Conference , January 1989.12. [Card et al. 1993] R. Card, E. Commelin, S. Dayras, and F. Mével. The MASIX Multi-Server Operating System. In OSF Workshop on Microkernel Technology for Distributed Systems , June 1993.13. [IEEE 1992] SECURITY INTERFACE for the Portable Operating System Interface for Computer Environments - Draft 13 . Institute of Electrical and Electronics Engineers, Inc, 1992.14. [Kleiman 1986] S. Kleiman. Vnodes: An Architecture for Multiple File System Types in Sun UNIX. In Proceedings of the Summer USENIX Conference , pages 260--269, June 1986.15. [McKusick et al. 1984] M. McKusick, W. Joy, S. Leffler, and R. Fabry. A Fast File System for UNIX. ACM Transactions on Computer Systems , 2(3):181--197, August 1984.16. [Seltzer et al. 1993] M. Seltzer, K. Bostic, M. McKusick, and C. Staelin. An Implementation of a Log-Structured File System for UNIX. In Proceedings of the USENIX Winter Conference , January 1993.17. [Tanenbaum 1987] A. Tanenbaum. Operating Systems: Design and Implementation . Prentice Hall, 1987. 18. Red Hat Enterprise Linux 4: Manual de referencia 19. “Design and Implementation of the Second Extended Filesystem” Rémy Card, Theodore Ts'o, and Stephen Tweedie First published in the Proceedings of the First Dutch International Symposium on LinuxAvailable on http://e2fsprogs.sourceforge.net/ext2intro.html20. “A Non-Technical Look Inside the EXT2 File System” Randy Appleton www.linuxgazette.com/issue21/ext2.html21. Whitepaper: Red Hat's New Journaling File System: ext3. Michael K. Johnson www.redhat.com/support/wpapers/redhat/ext3/22. ReiserFS Home Page www.namesys.com/23. “JFFS: The Journaling Flash File System”. David Woodhouse. http://sources.redhat.com/jffs2/jffs2.pdf24. README file from cramfs project Unsigned (assumed to be the project author). http://sourceforge.net/projects/cramfs/25. NFS home page. http://nfs.sourceforge.net26. The /proc file system documentation. www.tldp.org/LDP/lkmpg/2.6/html/c712.htm27. Embedded Linux Primer: A Practical, Real-World Approach.

13.2.Agradecimientos

Al Altísimo Dios, Creador del cielo y de la tierra, fuente de toda sabiduría y conocimento, y mi inspiración. A Lisandro que aporto valiosa bibliografía. A los profesores de Sistemas Operativos por sus valiosas enseñanzas. A todos muchas pero muchas GRACIAS!!!

Dios les re bendiga!!

monografia sistema de archivos 20120916

Documents