Capítulo 6: Operación de sistemas de archivos

Organización interna de FAT32

Para entender cómo se organiza un sistema de archivos, pondremos como ejemplo uno de los más sencillos: El sistema de archivos FAT32.

Lo primero que debemos saber es que la unidad mínima de asignación de espacio para un archivo es el clúster. Es decir, un archivo estará formado por uno o más clústers de un disco, que podrán estar en posiciones consecutivas o no consecutivas.

En principio, el número de clústers que se pueden direccionar, está en función del número de bits que se utilicen para crear las direcciones. Así, en FAT32 se utilizan 32 bits, lo que, en teoría, nos ofrecería un máximo de 2³² direcciones posibles (es decir, 4.294.967.296). Sin embargo , sólo se utilizan los 28 primeros (los 4 restantes están reservados), lo que nos ofrece un máximo de 2²⁸ clústers (es decir, 268.435.456).

FAT32 puede utilizar tamaños de clúster que oscilen entre 8 y 64 sectores. Esto significa que, si el tamaño de un sector suele ser 512 bytes, un clúster podría tener entre 4.096 y 32.768 bytes. Es decir, que podríamos formatear unidades comprendidas entre 1 TiB y 8 TiB.

Como dijimos más arriba, el nombre FAT proviene del inglés File Alocation Table, y el motivo es que el almacenamiento de archivos en el disco se organiza en forma de tabla. La longitud de cada entrada (fila) de dicha tabla será de 12, 16 o 32 bits según la versión de la que estemos hablando.

La tabla FAT tendrá una entrada por cada clúster del disco que pueda contener información y su valor podrá ser alguno de los siguientes:

• La dirección del siguiente clúster del mismo archivo.

• Una marca de fin de archivo (EOF, del inglés End of File) que indica que es el último clúster de ese archivo.

• Un indicativo de que el clúster está libre (en este momento no contiene información que pertenezca a ningún archivo).

• Una marca de clúster defectuoso.

En todas las versiones del sistema de archivos FAT que han ido apareciendo, el tamaño del clúster siempre ha estado relacionado con el tamaño del dispositivo. La explicación es muy sencilla: dado que el número máximo de clústers es fijo, cuanto más grande sea el volumen, más grandes tendrán que ser los clústers.

En la siguiente imagen podemos ver una representación simplificada de cómo se organiza una tabla FAT:

Así, en el ejemplo, el archivo A estaría ocupando los clústers 2, 6, 10 y 3, en ese orden.

Es habitual que la tabla FAT se encuentre duplicada en el soporte de manera que pueda usarse la segunda copia para recuperar la primera en el caso de que ésta se hubiese corrompido.

Inconvenientes del sistema de archivos FAT

Como habrás deducido de lo que hemos dicho más arriba, en un dispositivo de 1 TiB, un archivo con un solo byte, ocupará 4096 bytes en el disco (un clúster). Y bastaría con que tuviese 4097 para que ocupase dos clústers.

Por otro lado, para que el rendimiento sea elevado, la tabla FAT suele alojarse completa en la memoria RAM, con el consiguiente desperdicio de la misma. No obstante, si se trata de ahorrar memoria almacenando sólo la parte de la FAT que se esté utilizando, cuando el archivo se encuentre muy fragmentado, el sistema necesitará realizar accesos continuos a disco para obtener porciones de la FAT que no residan en la memoria.

Qué es un inodo

En los sistemas de archivos de la familia Unix (incluidos los sistemas operativos GNU/Linux), un inodo, o nodo-i, es la estructura de datos que se utiliza para representar cualquiera de los objetos del sistema de archivos, como archivos, directorios o enlaces simbólicos. Cada inodo contiene los atributos y la ubicación del bloque (o bloques) que almacenan la información del objeto en el disco. Dichos atributos pueden incluir metadatos (como el momento de la última modificación o acceso) e información sobre el propietario (usuario y grupo) y los permisos.

Un directorio no es más que un archivo, cuyo contenido es una lista enlazada de nombres asignados a inodos. Cada directorio contiene una entrada que lo representa a él mismo, otra para su directorio padre y una para cada uno de sus hijos. En este caso, los directorios se tratan como archivos.

Estructura de inodos en ext3

En total, en el sistema de archivos ext3, un inodo ocupa 128 bytes. Un tamaño muy conveniente, porque los bloques de almacenamiento en disco suelen ser de 4096 (4 x 2¹⁰) bytes, lo que permite almacenar hasta 32 inodos en un solo bloque.

Por otro lado, las direcciones de bloque se forman con 32 bits (4 bytes), Lo que implica que se podrán direccionar, en total, 2³² bloques distintos sobre el dispositivo de almacenamiento. Esto nos lleva a dispositivos con un tamaño máximo de 4 x 2¹⁰ x 2³² bytes, es decir, 4 x 2⁴² bytes. Teniendo en cuenta que 1 TiB son 2⁴⁰ bytes, también podríamos escribir la expresión como 4 x 2² x 2⁴⁰ bytes, que arroja un total de 16 TiB.

En definitiva, los inodos tienen la siguiente estructura:

• Un identificador del dispositivo que contiene al sistema de archivos.

• Un identificador de inodo que lo identifica dentro del sistema de archivos.

• La longitud del archivo (en bytes).

• El identificador del propietario del archivo

• Acceso (lectura, escritura, ejecución) para el propietario, su grupo y otros usuarios.

• Fechas de última modificación, último acceso, última modificación del inodo.

• El número de enlaces simbólicos. Es decir, el número de entradas de directorio que hacen referencia a este mismo archivo. Así, el archivo sólo se borrará cuando se elimine el último enlace que le hace referencia. De lo contrario, sólo se borra la entrada de directorio y se disminuirá en uno éste valor.

• Doce punteros con la dirección en el disco a los doce primeros bloques de datos del archivo. Se llaman punteros directos (en inglés, direct block pointers) y ocupan un total de 48 bytes (4 bytes x 12 direcciones).

• Un puntero de indirección simple, que contiene la dirección de un bloque de punteros que, a su vez, contienen las direcciones de bloques de datos del archivo.

• Un puntero de indirección doble, que contiene la dirección de un bloque de punteros que, a su vez, contienen la dirección de otros bloques de punteros que, finalmente, contienen las direcciones de bloques de datos del archivo.

• Un puntero de indirección triple, que contiene la dirección de un bloque de punteros que, a su vez, contienen la dirección de otros bloques de punteros que, a su vez, contienen la dirección de otros bloques de punteros que, finalmente, contienen las direcciones de bloques de datos del archivo.

Algo similar a lo que muestra la siguiente figura:

Así pues, cuando un archivo ocupa 12 bloques o menos, sólo necesitará utilizar los punteros directos:

De este modo, si estuviésemos utilizando bloques de 4096 bytes, significaría que los archivos que ocupen 48 KiB (12 x 4096 bytes = 49152 bytes = 48 KiB), o menos, sólo usarían direccionamiento directo.

Para los archivos de mayor tamaño, el sistema de archivos debe recurrir, en primera instancia, a los punteros indirectos simples, que utilizan un bloque de disco (4096 bytes) para guardar las direcciones de los siguientes bloques de datos. Suponiendo que estamos trabajando con longitudes de palabra de 32 bits (4 bytes), podríamos guardar un total de 1024 direcciones de bloques (4096 / 4).

Dado que ahora podemos direccionar 1024 (2¹⁰) nuevos bloques y cada uno de éstos tiene una capacidad de 4096 bytes, acabamos de obtener una capacidad máxima complementaria de 4 MiB (1024 x 4096 bytes = 4194304 bytes = 4 MiB).

Siguiendo la misma lógica, para los archivos que utilicen más de 4 MiB, el sistema de archivos recurrirá, a continuación, a los punteros indirectos dobles. En este caso, el puntero del inodo contiene la dirección de un bloque de disco donde se almacenan direcciones de bloques que, a su vez, contienen direcciones de otros bloques que son los que contienen los datos. Como ya sabemos que en cada bloque caben referencias a 1024 nuevos bloques, en este caso, la cantidad máxima de bloques de datos a los que se puede hacer referencia son 1024 x 1024 (2²⁰) = 1048576.

Así pues, usando punteros indirectos dobles, el sistema de archivos puede almacenar 4 GiB (1024 x 1024 x 4096 bytes = 4294967296 bytes = 4 GiB).

Como cabe esperar, siguiendo la misma lógica, los punteros indirectos triples son capaces de hacer referencia a 1073741824 bloques de datos distintos (1024 x 1024 x 1024 ó 2³⁰).

Esto significa que, usando punteros indirectos triples, el sistema de archivos puede almacenar 4 TiB de datos (1024 x 1024 x 1024 x 4096 bytes = 4398046511104 bytes = 4 TiB).

En definitiva, el tamaño máximo de un archivo en un dispositivo de almacenamiento que utilice ext3 será de 4 TiB + 4GiB + 4 MiB + 48 KiB.

Cambios para el diseño de ext4

El primer cambio significativo que se aplicó en ext4 respecto al diseño de los inodos es que el direccionamiento emplea 48 bits (en lugar de los 32 anteriores). Esto permite dar soporte a dispositivos que lleguen al 1 EiB de tamaño.

Además, en lugar de utilizar bloques indirectos, se usan extents, que son elementos formados por dos valores enteros de 48 bits. El primero de ellos indica un número de bloque inicial y el segundo la cantidad de bloques contiguos ocupados. Ahora, las 15 direcciones de bloque (60 bytes) que usaba ext3 en cada inodo (12 directas + 1 indirecta + 1 doble-indirecta + 1 triple-indirecta), se utilizan en ext4 para almacenar 4 extents y una cabecera (todas ellas de 12 bytes).

A pesar de todo, cuando un archivo está muy fragmentado, puede necesitar un número más elevado de extents. En ese caso, las extents complementarias se organizarán a modo de árbol con organización HTree. La raíz del árbol se almacena dentro de la estructura del inodo y los extents se almacenan en los nodos hoja del árbol.

Cada nodo comienza con una cabecera de extents, que contiene el número de entradas válidas para el nodo, la capacidad de las entradas que almacena el nodo, la profundidad del árbol y un número, llamado mágico, que permite diferenciar entre diferentes versiones de las extents (permitiendo añadir características nuevas en el futuro, como el incremento de direcciones de bloque a 64 bits).

Sin embargo, ext4 trata de reducir la fragmentación al mínimo.

El sistema de archivos ZFS

ZFS es un sistema de archivos que está adquiriendo relevancia en los últimos tiempos. Entre otras cosas, porque Canonical ha decidido incluirlo, de forma experimental, en Ubuntu 19.10, como un reemplazo del habitual ext4.

Como hemos dicho más arriba, su desarrollo se inició en Sun Microsystems. Sin embargo, tras la compra de Sun Microsystems por parte de Oracle, buena parte de los desarrolladores de ZFS abandonaron la compañía y crearon el proyecto OpenZFS en septiembre de 2013.

Inicialmente, su nombre provenía de Zettabyte File System aunque, posteriormente, se simplificó a Z File System.

Fundamentalmente, ZFS trata de centrarse en dos objetivos principales:

• El soporte de grandes cantidades de información: Como hemos dicho, admite archivos de 16 exabytes y volúmenes de hasta los 256 x 10¹⁵ zettabytes.

• Impedir que la información contenida se corrompa: Para lograrlo usa la técnica Copy-on-write, que consiste en no sobreescribir los datos actualizados. En su lugar, se utiliza un nuevo bloque de disco

Copy-on-write permite crear fácilmente instantáneas del sistema de archivos, que contendrán la versión del sistema de archivos en un momento determinado. De este modo, podrá montarse una instantánea en modo de solo lectura para recuperar la versión antigua de uno o varios archivos. Incluso podremos devolver todo el sistema al estado que tenía en una instantánea anterior y anular los cambios realizados con posterioridad.

También, se incorpora un checksum en cada archivo para detectar si se ha corrompido. En caso afirmativo, ZFS tratará de repararlo automáticamente.

Además de lo dicho hasta ahora, ZFS aún aporta dos ventajas más:

• Administración de volúmenes: ZFS puede crear un sistema de archivos sobre un conjunto de dispositivos físicos. Pudiendo añadir más unidades a lo largo del tiempo.

• Manejo de RAID sin software o hardware complementario: De hecho, ZFS incorpora su propia implementación de RAID, llamada RAID-Z (en realidad, una versión más fiable de RAID-5).

¿Qué es FUSE?

Tradicionalmente, los sistemas de archivos en los sistemas operativos UNIX y derivados se han construido como un módulo del núcleo. De este modo, cuando un usuario (o un programa) realiza una solicitud, ésta se convierte en una llamada al sistema y se ejecuta en el sistema de archivos, usando el modo privilegiado.

A partir de la versión 2.6.14 del núcleo de Linux, se incluye FUSE (Filesystem in Userspace) para dar soporte a sistemas de archivo que puedan ejecutarse en modo usuario.

FUSE es un módulo del núcleo que recibe las solicitudes de los usuarios (o programas) y los pasa a un sistema de archivos que se está ejecutando en modo usuario. Así, los usuarios pueden generar sistemas de archivo sin que sea necesario modificar el núcleo del sistema operativo. Además, se incrementa el número de sistemas de archivo a los que puede dar soporte el sistema operativo.

De hecho, este es el método que se utiliza para dar soporte a NTFS o EncFS (además de los ya mencionados archfs y nntpfs) y permite montar discos duros virtuales (por ejemplo, archivos vdi) como si fuesen físicos.

Veamos, por ejemplo, el enfoque para NTFS:

El inconveniente es que, los cambios en el modo de ejecución y la transferencia de datos penalizan el rendimiento.

Como vemos, el funcionamiento de FUSE se apoya sobre VFS (del inglés, Virtual File System), que no es más que una capa de software que actúa como intermediario entre las aplicaciones y el sistema de archivos real. De este modo, se consigue un acceso uniforme a sistemas de archivos con arquitecturas diferentes.