INF413

6.2 REPRESENTACION INTERNA DE ARCHIVOS

6.2.1 Ínodos

El lugar permanente de los ínodos es el disco, y es de allí que los lee el kernel para luego
llevarlos a memoria principal y proceder con el trabajo respectivo. Los campos contenidos en un
ínodo son:

Dueño abc
Grupo sr
Tipo archivo regular (directorio/bloque especial)
Permiso rwxr_xr_x
Acceso nov 3 1998 6:30 pm
Modificado oct 31 1998 11:00 pm
Ínodo nov 1 1998 9:15 am
Tamaño 1000 bytes
Dirección del disco

El contenido de un ínodo cambia cuando se cambia el contenido del archivo o cuando se

cambia su dueño, los permisos o los punteros. El cambio del contenido del archivo implica el
cambio automático en el ínodo, pero no viceversa.

6.2.2 Asignación de ínodos a nuevos archivos

Cuando un proceso requiere un nuevo ínodo, el kernel tendría que buscar en la lista de ínodos
libres. Sin embargo, una búsqueda de ese tipo podría resultar costosa puesto que se requiere al
menos una operación de lectura (desde disco posiblemente) por cada ínodo. Para mejorar el
desempeño el superbloque del sistema de archivos contiene un arreglo del número de ínodos
libres (similar a una memoria cache) en el sistema de archivos.
Si la lista de ínodos libres del superbloque está vacía, el kernel examina el disco y coloca la
mayor cantidad de números de ínodos libres en el superbloque. El kernel lee la lista de ínodos
libres del disco bloque a bloque y llena la lista de ínodos del superbloque hasta su capacidad,
recordando el ínodo con el número mayor que fue encontrado. A dicho nodo se llama
“remembered” el cual fue el último salvado en el superbloque. La próxima vez que el kernel
examine el disco buscando ínodos libres, utilizara el ínodo “remembered” como su punto de
partida de modo que la búsqueda no se efectúe donde no deberían existir ínodos libres.

6.2.3 Asignación de bloques de disco

Toda vez que un proceso escribe un archivo el kernel debe asignar bloques de disco. El
superbloque contiene un arreglo (similar a una memoria cache) utilizando para colocar los
números de bloque libres de disco. El programa utilitario mkfs organiza los bloques de datos
mediante una lista encadenada de manera que cada eslabón de la lista es un bloque de disco que
contiene un arreglo de números de bloques de disco que están libres, y una entrada del arreglo es
el número del siguiente bloque de la lista encadenada.

1
 INF413

Lista del superbloque

109 106 103 100

109
211 208 205 202 112

211
310 307 304 301 214

310
409 406 403 400 313

Lista encadenada de números de bloques libres en disco

Cuando el kernel requiere asignar un bloque, asigna el próximo bloque disponible en la

lista del superbloque. Si el bloque asignado es el último disponible en el superbloque (cache),
el kernel considera a ese número como un puntero a un bloque que contiene una lista de
bloques libres.

Si un proceso escribe gran cantidad de datos en un archivo, sus requerimientos de bloque

serán frecuentes, pero el kernel le asigna un bloque por vez. El programa mkfs procura
organizar la lista original encadenada de números de bloques libres de manera que las
distribuciones de bloques a un archivo resulten próximas entre sí. Eso mejora el desempeño
porque reduce el tiempo de búsqueda y el tiempo de latencia del disco cuando un proceso lee
un archivo en forma secuencial.

Los algoritmos para asignación y liberación de ínodos y de bloques de disco son similares
en el sentido que el kernel usa el superbloque como una (memoria) cache conteniendo índices
de recursos libres, números de bloques, y números de ínodos. Mantiene una lista encadenada
de números de bloques de manera que todo número de bloque libre se encuentra en la lista
encadenada, pero tal cosa no sucede con la lista de ínodos libres. Hay tres razones para ello:

1. El kernel puede determinar si un ínodo esta libre mediante inspección: si el campo “tipo
archivo” es vacío, el ínodo está libre. Sin embargo, no se puede seguir el mismo método
con bloque.
2. Los bloques de disco son apropiados para usar listas encadenadas: un bloque de disco
puede contener sin dificultad una lista grande de números de bloques libres. Pero los
ínodos no tienen el espacio suficiente para contener listas grandes de números de ínodos
libres.
3. Los usuarios consumen en mayor proporción bloques de disco que ínodos, de manera
que la aparente disminución en el desempeño cuando se examina el disco para ínodos
libres no es tan crítico como en una búsqueda de bloques libres.

6.2.4 Estructura de un archivo regular

2
 INF413

Como ya se indicó el ínodo contiene una tabla para ubicar los datos del archivo en el disco.
Puesto que cada bloque en un disco es direccionable por un número, el contenido de la referida
tabla es un conjunto de números de bloques de disco. Si el almacenamiento fuera contiguo en el
disco, entonces sería suficiente el número de bloque inicial y el tamaño del archivo. Sin
embargo, tal estrategia de asignación no permitiría una simple expansión y contracción de
archivo sin causar riesgos de fragmentación en el disco. Además, el kernel tendría que ubicar y
reservar espacio contiguo en el sistema de archivos antes de las operaciones para incrementar el
tamaño de un archivo.

Por ejemplo, suponiendo que un usuario crea tres archivos, A, B y C, cada uno de 10 bloques
de disco, y suponiendo que el sistema asigna almacenamiento contiguo para los tres archivos. Si
el usuario requiere añadir 5 bloques de datos en la mitad del archivo B, el kernel deberá copiar
el archivo B a un lugar del sistema de archivos suficiente para almacenar 15 bloques. Además
del costo de la operación, los bloques previamente ocupados por el archivo B podrán ser
utilizados solo por archivos con menos de 10 bloques (fragmentación externa). El kernel podría
minimizar la fragmentación realizando periódicamente compactaciones de las áreas libres, sin
embargo, esta acción podría afectar el rendimiento del sistema.

Para tener una mayor flexibilidad, el kernel almacena cada uno de los bloques del archivo de
acuerdo a la disponibilidad de bloques libres que tenga el sistema, quedando estos
desparramados. Pero este esquema de almacenamiento complica la tarea de ubicación de datos.
Una tabla para la búsqueda podría consistir de una lista de número de bloques que contengan los
datos del archivo, pero un simple cálculo muestra que una lista lineal de bloques del archivo en
el inodo tiene un manejo complicado. Si un bloque lógico tiene 1k bytes, entonces un archivo de
10k bytes requiere un índice con 10 números de bloques, pero un archivo de 100k bytes requiere
un índice con 100 números de bloques. Para cualquier caso el tamaño del inodo tendría que
variar de acuerdo al tamaño del archivo.

Para conservar la estructura del inodo pequeña aun tratándose de archivos grandes, la tabla de
contenidos de bloques de disco (Sistema UNIX V) consta de 13 entradas en la tabla de
contenidos de inodo, manteniendo la independencia con el número de entradas.

Los 10 primeros bloques (0 – 9) “directo” contienen números de bloques de disco, conteniendo

los datos. El bloque siguiente (10} “indirecto_ simple” contiene un número de bloque
conteniendo una lista de números de bloques “directo”. El bloque (11) “indirecto_ doble”
contiene una lista de números de bloques “indirecto_ simple”, El bloque (12) “indirecto_triple”
contiene una lista de números de bloques “indirecto_doble”.

Suponiendo que un bloque lógico en el sistema contiene 1k bytes y que un número de bloque
es direccionable por un entero de 32 bits (4 bytes). Entonces un bloque puede contener hasta
256 números de bloque. Siguiendo esta lógica el número máximo de bytes que podría contener
un archivo seria más de 16 gigabytes. Sabiendo que el campo para el tamaño de un archivo en el
inodo es 32 bits, el tamaño de un archivo efectivamente limitado a 4 gigabytes (2 32 =
4294967296 bytes).

Los procesos acceden a los datos de un archivo usando un byte offset. El método es mediante
el conteo de bytes, considerando un archivo como una serie (stream) de bytes que comienza en

3
 INF413

el byte con dirección 0 hasta el tamaño del archivo. El kernel muestra al usuario la secuencia de
bytes en término de bloques. El archivo empieza en el bloque lógico 0 y continua hasta el
número lógico de bloque correspondiente al tamaño del archivo. El kernel accesa al inodo y
convierte el bloque lógico del archivo en el bloque de disco correspondiente.

Suponiendo que un bloque de disco tiene 1024 bytes. Si un proceso requiere el acceso al byte
9000, el kernel calcula que ese byte se encuentra mediante el bloque 8 “directo” (empezando
desde 0); El byte 808 del bloque es el byte 9000 del archivo. Si un proceso requiere accesar al
byte offset 350000 del archivo, tendrá que hacerlo utilizando el direccionamiento
“indirecto_doble” (número 9156 en el ejemplo). Como un bloque indirecto direcciona 256
números de bloques, el primer byte accesado mediante el direccionamiento “indirecto doble” es
el byte número 272384 (256k + 10k); el byte número 350000 en un archivo corresponde al byte
número 77616 (350000 – 272384) del bloque “indirecto_doble”. Ya que cada bloque “indirecto
simple” tiene capacidad de acceso a 256 k bytes, el byte número 350000 estará en el “0” ésimo
bloque “indirecto sencillo” correspondiente a un bloque “indirecto doble” (número 331 en el
ejemplo). Puesto en que cada bloque directo en un bloque indirecto sencillo contiene 1 k bytes,
el byte número 77616 de un bloque indirecto sencillo está en el “75” ésimo bloque “directo”
correspondiente a un bloque “indirecto sencillo” (número 3333 en el ejemplo). Finalmente, el
byte número 350000 del archivo es el byte número 816 (del bloque 3333).