Sistemas de archivos

Un archivo es una secuencia persistente de bytes. El sistema de archivos almacena esos bytes sin decidir si representan texto, una imagen o código máquina. Un directorio da al archivo un nombre legible; su número de inodo lo identifica dentro del sistema de archivos.

Abre un archivo y comprueba el resultado

open(path, flags, mode) devuelve un descriptor de archivo, un entero no negativo que se usa en llamadas posteriores. Si hay un error, devuelve -1 y establece errno. Elige O_RDONLY, O_WRONLY o O_RDWR para el acceso. O_CREAT crea un archivo que no existe, O_TRUNC vacía un archivo existente y O_APPEND coloca cada escritura en el final actual.

Para un archivo nuevo, mode solicita permisos y la umask del proceso elimina bits. Si el directorio no tiene una lista de control de acceso (ACL) predeterminada, el resultado es mode & ~umask. Solicitar 0666 con umask 0022 da 0644, o rw-r--r--. Este argumento no cambia los permisos de un archivo que ya existe.

Los descriptores pertenecen a un proceso. Normalmente 0, 1 y 2 son la entrada, la salida y el error estándar. open elige el descriptor sin usar de menor valor, a menudo 3. En Linux, strace cat notes.txt muestra las llamadas: abrir la entrada, leerla, escribir en el descriptor 1 y después cerrar la entrada.

Sigue el desplazamiento, no la cantidad solicitada

read(fd, buf, n) devuelve el número de bytes realmente leídos, hasta n. Para una solicitud distinta de cero en un archivo normal, cero significa que no quedan bytes en el final del archivo o más allá; -1 indica un error. write también devuelve una cantidad real, que puede ser inferior a la solicitada. Comprueba esa cantidad antes de avanzar en un búfer o decidir que la operación ha terminado.

Supón que log.txt contiene 300 bytes. Cuatro solicitudes de 100 bytes devuelven 100, 100, 100 y 0. El desplazamiento, la posición de la siguiente operación, pasa a 100, 200, 300 y 300. El fin de archivo se indica mediante una cantidad devuelta, no mediante un byte especial almacenado en el archivo.

lseek(fd, 200, SEEK_SET) establece el desplazamiento en 200. Leer después 50 bytes devuelve los bytes 200 a 249 y deja el desplazamiento en 250. SEEK_CUR mide desde el desplazamiento actual; SEEK_END mide desde el final del archivo. Cambiar el desplazamiento modifica un número en memoria. No mueve un cabezal de disco ni lee datos por sí mismo. pread y pwrite usan una posición explícita sin cambiar este desplazamiento.

Determina qué descriptores comparten un desplazamiento

La tabla de descriptores del proceso apunta a entradas de la tabla de archivos abiertos del núcleo. Cada entrada de archivo abierto contiene el modo de acceso, el desplazamiento, una referencia al inodo y un contador de referencias.

Si un hijo sitúa un descriptor compartido en el byte 10, la siguiente lectura del padre mediante esa entrada también empieza en 10. El inodo identifica el archivo, pero la entrada de archivo abierto contiene el desplazamiento: dos lectores pueden compartir un archivo sin compartir su posición. La redirección del intérprete de comandos usa dup2 para que la salida estándar se refiera a otra entrada de archivo abierto. close libera un descriptor; la entrada desaparece cuando se libera su última referencia. Cerrar por sí solo no fuerza la escritura de los datos en búfer en almacenamiento estable.

Una escritura que termina correctamente y una actualización resistente a fallos responden a preguntas distintas. Una escritura informa de que se han aceptado los bytes. La durabilidad plantea si sobreviven a un fallo; la atomicidad plantea si una actualización solo puede observarse como un todo.

Fuerza la escritura de los bytes en almacenamiento estable

Los sistemas operativos suelen almacenar las escrituras en búfer en memoria y enviar los bloques modificados al almacenamiento más tarde, a menudo en unos 5 a 30 segundos. Esto combina escrituras pequeñas y permite que el programa continúe rápidamente. Un fallo puede borrar los datos que aún esperan en esos búferes.

fsync(fd) fuerza la escritura de los datos y metadatos modificados del archivo en el almacenamiento y espera a que el dispositivo informe de que ha terminado. Un programa debe comprobar el resultado antes de comunicar que el guardado es duradero. close libera el descriptor y no sustituye esta espera.

Un archivo también necesita un nombre duradero. La entrada que relaciona el nombre con el inodo es un dato que pertenece a su directorio, no al archivo. Después de crear un archivo, sincronizar solo el archivo puede hacer que sus bytes sean duraderos sin garantizar que sobreviva su nuevo nombre. Abre el directorio que lo contiene y sincronízalo cuando el nombre deba persistir.

Sustituye un archivo sin exponer una versión parcial

Sobrescribir un documento en su ubicación crea un intervalo en el que los lectores pueden encontrar contenido incompleto. O_TRUNC primero establece su longitud en cero. Si un fallo interrumpe las escrituras posteriores, la copia antigua completa ya ha desaparecido.

En su lugar, escribe el contenido de sustitución con un nombre temporal en el mismo directorio. Después usa rename para sustituir el destino. Para un destino existente en el mismo sistema de archivos, POSIX hace que esa sustitución sea atómica: el nombre de destino se refiere al archivo antiguo o al de sustitución, sin un momento intermedio en el que falte el nombre. Los lectores no ven una mezcla de sus contenidos a través de ese nombre.

Para settings.json, la secuencia de sustitución duradera es:

1. Escribe todo el contenido nuevo en settings.json.tmp y comprueba si hay escrituras parciales o errores.
2. Llama a fsync sobre el archivo temporal y comprueba que se complete correctamente.
3. Llama a rename("settings.json.tmp", "settings.json") y comprueba que se complete correctamente.
4. Llama a fsync sobre el directorio que lo contiene y comprueba que se complete correctamente.

El archivo temporal está completo y es duradero antes de que cambie el nombre. La sincronización final del directorio hace duradero ese cambio de nombre. Un fallo durante la secuencia deja en el destino la versión antigua completa o la nueva completa; después de que la sincronización final termine correctamente, la nueva versión es la duradera. La sustitución atómica del nombre por sí sola no garantiza que un cambio de nombre sin sincronizar sobreviva a un corte de energía.

rename entre sistemas de archivos falla con EXDEV. Un comando que responde copiando y eliminando realiza varias operaciones, por lo que esa alternativa no garantiza la sustitución atómica.

Cambia la longitud sin escribir todos los bytes

truncate(path, length) y ftruncate(fd, length) establecen la longitud del archivo. Reducirla descarta los bytes situados más allá del nuevo final. Ampliarla hace que la nueva región se lea como ceros. Situar el desplazamiento más allá del final y después escribir también crea un hueco que se lee como ceros.

Un archivo disperso puede representar ese hueco sin asignarle bloques de datos. Partiendo de un archivo vacío, escribir un byte en el desplazamiento 8192 crea un archivo de 8193 bytes; la región anterior sin escribir se lee como ceros. Su tamaño lógico puede superar el espacio asignado físicamente.

Los directorios separan los nombres que usan las personas de los objetos que almacena el sistema de archivos. Cada directorio tiene su propio inodo y bloques de datos; sus entradas relacionan nombres con números de inodo.

Sigue las rutas a través del árbol

Una ruta absoluta empieza en /. Una ruta relativa empieza en el directorio de trabajo actual del proceso. La entrada . nombra el propio directorio y .. nombra su directorio padre; el padre de la raíz es la propia raíz. Desde /home/lee, la ruta relativa ../shared llega a /home/shared.

Una extensión como .txt forma parte de un nombre. Los programas pueden usarla para elegir cómo interpretar los bytes, pero el sistema de archivos no exige que un archivo .txt contenga texto.

mkdir crea un directorio que contiene . y ... Para listar las entradas, un programa usa opendir, llama a readdir hasta que no queden entradas y llama a closedir. Un resultado de readdir incluye un nombre y un número de inodo. Los programas cambian el contenido de los directorios mediante llamadas como link, unlink y rename, no mediante llamadas ordinarias a write. rmdir elimina un directorio vacío.

Da a un archivo dos nombres equivalentes

link(old, new) crea un enlace duro: otra entrada de directorio que apunta al mismo inodo. Ninguno de los nombres tiene el privilegio de ser el original. El número de enlaces del inodo registra cuántos nombres se refieren a él.

Considera estos comandos cuando ningún proceso mantiene abierto el archivo:

echo hi > a
ln a b
rm a
cat b
rm b

Crear b aumenta el número de enlaces de 1 a 2. Eliminar a lo reduce a 1; b sigue dando acceso a los mismos bytes, por lo que cat b imprime «hi». Eliminar b reduce el número a 0, lo que permite recuperar el inodo y sus bloques.

Un descriptor abierto añade una segunda regla sobre el tiempo de vida. Si se elimina el último nombre mientras un proceso todavía tiene abierto el archivo, ese proceso puede seguir accediendo a él. La recuperación espera tanto a que haya cero enlaces como a que no haya referencias abiertas. Esto explica por qué eliminar un archivo de registro grande que está abierto puede no liberar su espacio de inmediato.

Un enlace duro no puede cruzar sistemas de archivos: el número de inodo del destino no tendría significado en la otra tabla de inodos. La mayoría de los sistemas Unix también prohíben los enlaces duros a directorios para conservar un árbol sin ciclos. En el recuento clásico de directorios de Unix, un directorio vacío tiene dos enlaces, el de su entrada en el directorio padre y el de su propia entrada .. Cada subdirectorio aporta uno más mediante ..; tres subdirectorios dan un número de 5.

Almacena una ruta en un enlace simbólico

Un enlace simbólico es un archivo independiente cuyo contenido es una ruta de destino. ln -s /home/ana/report.txt r crea r con la ruta de destino de 20 bytes como contenido. Al seguirlo se resuelve esa ruta. Los enlaces simbólicos pueden cruzar sistemas de archivos y apuntar a directorios.

Un enlace simbólico no aumenta el número de enlaces de su destino. Por tanto, conservar el objeto de enlace no mantiene disponible el destino.

El contenido de un archivo es solo una parte de su estado. Los metadatos registran quién puede usarlo, su tamaño y tipo, y cuándo cambió. El montaje permite acceder a objetos de varios sistemas de archivos a través de un único árbol de nombres.

Interpreta correctamente los metadatos

stat(path, &buf) lee los metadatos mediante una ruta; fstat(fd, &buf) los lee mediante un descriptor abierto. Los resultados incluyen el número de inodo, el tipo, los permisos, los identificadores de propietario y grupo, el tamaño, los bloques asignados y el número de enlaces. El tamaño del archivo cuenta los bytes lógicos; los bloques asignados miden el almacenamiento realmente utilizado, que puede ser menor en un archivo disperso.

Tres marcas de tiempo describen eventos diferentes:

ctime no es la fecha de creación. Actualizar solo atime no cambia ctime. La llamada stat de Unix clásico no tiene un campo de fecha de creación; statx de Linux puede mostrar una fecha de creación registrada cuando el sistema de archivos la admite.

Interpreta los bits de permisos

Los derechos de lectura, escritura y ejecución se registran por separado para el propietario, el grupo y los demás. Cada clase es un dígito octal: lectura vale 4, escritura 2 y ejecución 1. Para rw-r-----, el propietario recibe 4 + 2 = 6, el grupo recibe 4 y los demás reciben 0. chmod 640 report.txt establece esos bits.

Los permisos de directorio se aplican a los nombres y al recorrido. La lectura permite listar nombres. La ejecución permite la búsqueda, es decir, usar el directorio en una ruta. La escritura junto con la ejecución permite crear, eliminar y renombrar entradas. Conocer un nombre puede bastar para abrir un archivo en un directorio con permiso de ejecución, pero sin permiso de lectura, siempre que los permisos del propio archivo permitan el acceso. Aun así, listar ese directorio falla.

Esta diferencia importa para la eliminación: eliminar una entrada modifica el directorio que la contiene. El bit de escritura de un archivo controla la modificación de sus bytes; no es el permiso del directorio para eliminar su nombre. Root elude la mayoría de las comprobaciones ordinarias de permisos. Las listas de control de acceso (ACL) pueden conceder derechos a usuarios y grupos identificados por su nombre, además de las tres clases básicas.

Conecta otro sistema de archivos

mkfs inicializa un sistema de archivos en una partición u otro dispositivo, incluidos su propio directorio raíz y sus metadatos. Destruye el contenido anterior del sistema de archivos del dispositivo, así que ejecútalo solo en un dispositivo destinado a la inicialización.

mount conecta esa raíz a un directorio existente llamado punto de montaje. Una unidad montada en /media/usb hace accesible allí el contenido de su raíz. El contenido anterior de /media/usb queda oculto mientras el montaje está activo; montar no lo combina con el árbol montado. Ejecutar mount sin argumentos lista los montajes actuales.

La capa de sistema de archivos virtual (VFS) del núcleo ofrece una interfaz común a ext4, XFS, FAT y los sistemas de archivos en memoria y de red. Los programas pueden llamar a open y read a través de cualquiera de ellos. El espacio de nombres combinado no combina sus tablas de inodos: números de inodo iguales en distintos sistemas de archivos pueden identificar archivos sin relación. Por tanto, los enlaces duros y los cambios de nombre atómicos permanecen dentro de su propio sistema de archivos.

Un sistema de archivos debe recordar tanto dónde están los bytes como qué espacio está disponible. Una organización sencilla de estilo Unix hace visibles estas tareas al separar los registros de asignación, los inodos y el contenido.

Divide la partición en regiones

Un bloque es la unidad básica de asignación del sistema de archivos. Un bloque de 4 KiB contiene 4096 bytes, u ocho sectores tradicionales de 512 bytes. Los tamaños binarios usan KiB, MiB y GiB; las tasas de transferencia como MB/s usan millones decimales de bytes por segundo.

El diseño didáctico vsfs, el sistema de archivos muy sencillo, contiene estas estructuras:

Un bit de mapa de valor 1 significa asignado; 0 significa libre. El superbloque indica al sistema operativo cómo interpretar el resto de la partición al montarla. Los dos mapas de bits describen recursos distintos: un archivo puede tener un inodo asignado antes de tener bloques de datos.

Localiza un inodo por su número

Toma una partición de 64 bloques de 4 KiB. Coloca el superbloque en el bloque 0, el mapa de bits de inodos en el 1, el mapa de bits de datos en el 2 y la tabla de inodos en los bloques del 3 al 7. Los datos ocupan los bloques del 8 al 63. Cinco bloques de la tabla de inodos con inodos de 256 bytes contienen 80 inodos, porque cada bloque contiene 16. Hay 56 bloques de datos. Un mapa de bits de 4 KiB puede describir 32 768 objetos, por lo que gran parte de cada mapa queda sin usar en esta pequeña organización.

Numerando las posiciones de inodo desde cero, el inodo 37 comienza 37 × 256 = 9472 bytes después del inicio de la tabla. La tabla empieza en el byte 12 288, lo que da una dirección absoluta de byte de 21 760. Dividir entre 4096 da el bloque de disco 5 con resto 1280. Dividir entre 512 da el sector 42 con resto 256. Lee el bloque o sector que lo contiene y selecciona en él los bytes del inodo.

El método general es: inicio de la tabla en bytes más el número de inodo multiplicado por el tamaño del inodo. Mantén separada la dirección inicial de la tabla del desplazamiento del inodo dentro de ella. Omitir esa dirección base lleva a localizar un bloque de disco equivocado.

Separa nombres, metadatos y contenido

Un inodo, o nodo índice, registra el tipo, los permisos, la propiedad, el tamaño, las marcas de tiempo, el número de enlaces, los bloques asignados y las ubicaciones de los datos. No contiene el nombre del archivo. El nombre pertenece a una entrada de directorio, lo que permite que varios nombres compartan un inodo.

Un directorio tiene un inodo de tipo directorio y bloques de datos con entradas. Una entrada sencilla almacena un número de inodo, la longitud del registro, la longitud del nombre y el nombre. La longitud del registro permite saltar la entrada completa durante el recorrido, incluido el espacio reutilizable que queda al eliminar. Los directorios grandes se benefician de los índices: XFS usa árboles B y ext4 usa índices de árbol con hash.

Crear un archivo requiere encontrar y activar un bit libre en el mapa de bits de inodos. Asignar datos modifica de forma similar el mapa de bits de datos. Un asignador puede reservar una secuencia de bloques para que el archivo pueda crecer de forma contigua. El mapa de bits indica si un bloque está libre; el inodo indica a qué archivo pertenece. Estas estructuras deben concordar.

Un programa ve desplazamientos de bytes consecutivos, pero los bloques de datos correspondientes pueden estar dispersos por el disco. El sistema de archivos necesita una correspondencia entre cada bloque lógico del archivo y su ubicación física.

Sigue los punteros directos e indirectos

Un puntero directo de un inodo indica un bloque de datos. Con bloques de 4 KiB, el desplazamiento de byte 10 000 está en el bloque lógico 2, porque dos bloques completos usan 8192 bytes. El desplazamiento dentro de ese bloque es 1808. Los bloques lógicos empiezan en 0, así que el bloque 2 usa el tercer puntero directo.

Un puntero indirecto indica un bloque que contiene direcciones de bloques de datos. Un bloque de 4096 bytes con direcciones de 4 bytes contiene 1024 punteros. Un puntero doblemente indirecto indica un bloque cuyos punteros llevan a 1024 bloques indirectos. La indirección triple añade otro nivel. Este índice multinivel está desequilibrado a propósito: los archivos pequeños usan punteros directos sin lecturas adicionales de bloques de punteros, mientras que los archivos grandes asumen el coste de niveles adicionales.

Para un inodo con 12 punteros directos y un puntero de cada nivel de indirección:

Estas son las capacidades de esta organización de punteros. Los bloques de punteros también ocupan almacenamiento, pero sus bytes no son contenido del archivo.

Cuenta los bloques de punteros de un archivo

Un archivo de 5 MiB ocupa 1280 bloques de datos de 4 KiB cada uno. Asigna los primeros 12 a punteros directos. Asigna los siguientes 1024 al bloque indirecto simple. Quedan 244 bloques de datos.

Esos 244 necesitan una raíz doblemente indirecta y un bloque indirecto por debajo. En total, el archivo necesita tres bloques de punteros: el bloque indirecto simple, la raíz doblemente indirecta y su único bloque hijo. Contar solo la raíz doblemente indirecta deja fuera el bloque hijo que realmente contiene las direcciones de datos. Contar los 1024 posibles bloques hijos desperdicia espacio: solo se asigna el bloque hijo necesario.

Compara extensiones y cadenas

Una extensión registra un bloque inicial de disco y la longitud de una secuencia. Una secuencia contigua de 1000 bloques puede usar una extensión en lugar de 1000 punteros separados. Ext4, XFS y NTFS usan extensiones. Ext4 puede contener hasta cuatro extensiones en su inodo y usa un árbol para las adicionales. La fragmentación divide las secuencias y aumenta el número de registros de extensión necesarios.

La asignación enlazada sigue una cadena de bloques. La tabla de asignación de archivos (FAT) almacena los enlaces al siguiente bloque en una tabla separada, normalmente en caché en memoria. Una entrada de directorio identifica el primer bloque y llegar a un bloque situado más adelante requiere seguir los enlaces anteriores. FAT no usa inodos de Unix y no admite dos enlaces duros a un mismo archivo.

Los desplazamientos consecutivos nunca demuestran la contigüidad física. El asignador elige las ubicaciones y la correspondencia registra esas decisiones.

Una llamada al sistema puede requerir varias operaciones de disco o ninguna. Para seguir el trabajo, recorre las estructuras que el sistema de archivos debe consultar e indica cuáles están ya en caché.

Recorre una ruta antes de leer el contenido

En el modelo sencillo sin caché, abrir /docs/plan.txt lee cinco bloques:

1. El inodo de la raíz, cuyo número es conocido.
2. Los datos del directorio raíz, para encontrar docs.
3. El inodo de docs.
4. Los datos del directorio docs, para encontrar plan.txt.
5. El inodo del archivo.

Cada directorio cabe en un bloque y ningún bloque necesario está inicialmente en memoria. El sistema de archivos comprueba los permisos y crea una entrada de archivo abierto. La apertura ha encontrado los metadatos del archivo; todavía no ha leído su contenido. En ext2 y ext4 se usa el número 2 para el inodo de la raíz.

En un modelo de lectura deliberadamente sin caché, cada lectura de bloque lee después el inodo del archivo, lee los datos y escribe la hora de acceso del inodo. Dos bloques añaden seis operaciones de entrada/salida, lo que da once incluida la apertura. En este modelo, cerrar no requiere entrada/salida de disco. Estas cuentas describen las reglas explícitas de relectura y marcas de tiempo del modelo; una caché real las modifica.

Ten en cuenta la asignación durante la creación

Crear /docs/log.txt requiere algo más que encontrar un inodo existente. En el mismo modelo sencillo, realiza cuatro lecturas para los inodos de la raíz y de docs y los datos de sus directorios. Leer y escribir el mapa de bits de inodos añade dos operaciones de entrada/salida. Actualizar los datos de docs añade una escritura. Leer y escribir el nuevo inodo añade dos, y actualizar el inodo de docs añade una. Total: diez.

Cada bloque de datos recién asignado añade cinco operaciones de entrada/salida: leer y escribir el mapa de bits de datos, leer y escribir el inodo del archivo y escribir el bloque de datos. Por tanto, dos bloques dan veinte operaciones de entrada/salida incluida la creación. Este seguimiento cuenta las estructuras de datos sencillas antes de añadir el tráfico del registro en diario o el comportamiento de una caché real.

Llevar un registro ayuda: anota la estructura, si se lee o se escribe y por qué. Una escritura de datos también necesita un registro de asignación y una actualización de puntero. Un cambio de directorio también modifica los metadatos de ese directorio.

Deja que la caché cambie el seguimiento

Un acierto de caché usa un bloque que ya está en memoria. Linux usa una caché de páginas unificada compartida con la memoria virtual, no una caché de archivos de tamaño fijo permanentemente separada. Una apertura repetida puede reutilizar los bloques de directorios e inodos del recorrido anterior. Leer contenido en caché no necesita ninguna lectura del dispositivo. La política habitual relatime de Linux también evita una escritura de atime en cada lectura.

El almacenamiento temporal de escrituras en búfer retrasa el envío de bloques modificados al disco. La creación de dos archivos con poca diferencia de tiempo puede actualizar el mismo mapa de bits de inodos en memoria y escribirlo después una sola vez. El sistema de archivos puede reordenar el trabajo para mejorar la tasa de procesamiento. Un archivo temporal de corta vida puede crearse y eliminarse antes de que su contenido llegue al almacenamiento.

El uso de búferes mejora el rendimiento, pero deja un intervalo sin garantía de durabilidad. fsync cierra ese intervalo para un archivo al esperar las escrituras necesarias. O_DIRECT de Linux permite que los programas adecuados omitan la caché de páginas cuando gestionan sus propios búferes; omitir una caché no es por sí mismo la misma operación que sincronizar el almacenamiento duradero.

Un disco duro puede transferir rápidamente una larga secuencia de bytes una vez que su cabezal llega a ellos. Las solicitudes pequeñas y dispersas desperdician tiempo en búsquedas y esperas de rotación. Fast File System cambia la colocación para que las operaciones habituales con archivos utilicen más ancho de banda de transferencia del disco.

Diagnostica la antigua organización de Unix

La primera organización de Unix colocaba todos los inodos cerca del inicio y todos los datos de archivos después. Por ello, leer un archivo podía requerir una búsqueda larga desde los metadatos hasta el contenido. Una lista de bloques libres dispersaba gradualmente las asignaciones a medida que se creaban y eliminaban archivos. Incluso un archivo secuencial podía convertirse en muchos accesos a disco sin relación entre sí.

Los bloques pequeños de 512 bytes empeoraban la situación. Cada demora de posicionamiento solo permitía una transferencia corta antes de que la siguiente solicitud necesitara otra búsqueda o espera de rotación. Las mediciones históricas mostraron que el diseño antiguo llegaba a ofrecer tan solo el 2 % del ancho de banda del disco. Esa cifra describe el primer diseño medido, no un límite fijo de las interfaces de Unix.

El Fast File System (FFS), desarrollado en Berkeley a principios de la década de 1980, mantuvo llamadas conocidas como open, read y write mientras cambiaba la organización y la política de asignación. Los bloques mayores, normalmente de 4 KiB, aumentaban los bytes transferidos por solicitud. Mantener próximos los metadatos y el contenido reducía la distancia entre solicitudes relacionadas.

Construye grupos con sus propios recursos

Un cilindro es el conjunto de pistas situadas al mismo radio en las superficies de los platos de un disco. FFS forma grupos de cilindros con cilindros vecinos. Un archivo puede tener su inodo y sus datos en el mismo grupo, lo que mantiene corta la búsqueda desde los metadatos hasta los datos.

Cada grupo contiene una copia del superbloque, sus propios mapas de bits de asignación de inodos y datos, parte de la tabla de inodos y bloques de datos. El grupo se parece a un pequeño sistema de archivos, pero todos los grupos pertenecen a un mismo sistema de archivos. Una copia del superbloque también ayuda a la recuperación si una de ellas resulta dañada. Ext4 mantiene copias en determinados grupos en lugar de en todos.

Las unidades modernas ocultan su geometría física. Por ello, ext2, ext3 y ext4 usan grupos de bloques, secuencias de direcciones de bloques lógicos consecutivas, para perseguir el mismo objetivo de localidad sin depender de cilindros exactos.

Sigue la creación de un archivo pequeño

Crear /docs/a.txt necesita un inodo libre, un bloque de datos, cambios en los mapas de asignación y una nueva entrada de directorio. FFS intenta colocar el archivo en el grupo de su directorio padre. El inodo nuevo, los datos del archivo, los mapas de bits y las actualizaciones del directorio pueden quedar entonces próximos.

La operación sigue necesitando varias actualizaciones distintas. La agrupación ahorra tiempo de posicionamiento; no reúne todos los metadatos y datos en un solo bloque. Una organización que tiene en cuenta el disco reduce el coste de llegar a esas estructuras sin cambiar las operaciones con archivos del programa.

FFS usa los nombres como indicios de qué archivos accederá conjuntamente un programa. También limita cuánto espacio puede ocupar un archivo grande en un grupo, equilibrando la localidad con el espacio para futuras asignaciones.

Coloca directorios y archivos

Un directorio nuevo va a un grupo con relativamente pocos directorios y muchos inodos libres. Esto distribuye los distintos directorios y deja espacio para sus futuros archivos. El inodo de un archivo normal va en el grupo de su directorio padre y sus datos van cerca de su inodo.

Para /a/b, /a/c y /a/d, los tres archivos se colocan cerca del directorio /a. Un archivo /b/f sigue a su propio directorio padre /b, normalmente a otro grupo. Esto aprovecha la localidad en el espacio de nombres: un compilador que trabaja en un proyecto suele abrir varios archivos del mismo directorio. La relación de directorio predice patrones de acceso; no es una garantía para todos los programas.

Haz una excepción para un archivo grande

Un archivo grande podría consumir los bloques libres de su grupo y obligar a colocar todos los vecinos posteriores en otro lugar. FFS mantiene la primera parte, accesible mediante 12 punteros directos, en el grupo del inodo. Con bloques de 4 KiB son 48 KiB. Los fragmentos posteriores, cada uno accesible mediante un bloque indirecto que contiene 1024 punteros, abarcan 4 MiB de datos y van a otros grupos poco utilizados.

Esto sacrifica parte de la localidad dentro del archivo grande para conservar la localidad de los demás archivos del directorio. El archivo grande asume una demora de posicionamiento entre fragmentos, por lo que cada fragmento debe ser lo bastante grande para que ese coste merezca la pena.

Deduce el tamaño del fragmento

Sea T el tiempo de posicionamiento en segundos y R la tasa de transferencia en bytes por segundo. Un fragmento C tarda C/R segundos en transferirse. La fracción del tiempo total dedicada a la transferencia es:

Al despejar se obtiene:

A 100 MB/s con 10 ms de posicionamiento, R por T es 1 MB. Un fragmento de 1 MB necesita 10 ms de transferencia más 10 ms de posicionamiento, lo que da el 50 % del ancho de banda máximo. Para el 90 %, multiplica 1 MB por 0,9/0,1 y obtén 9 MB. Para el 99 %, el multiplicador es 99, lo que da 99 MB. Convierte milisegundos a segundos antes de multiplicar por MB/s. El denominador incluye tanto el tiempo de transferencia como el de posicionamiento; dividir solo entre el tiempo de transferencia ocultaría la sobrecarga.

Las tasas de transferencia han mejorado más rápido que las demoras de posicionamiento, por lo que alcanzar la misma fracción del máximo requiere fragmentos mayores a medida que aumenta la diferencia.

Aloja archivos pequeños y conserva la compatibilidad

FFS también usaba subbloques de 512 bytes para que los archivos pequeños no desperdiciaran un bloque completo de 4 KiB. Los archivos que crecían se copiaban a bloques completos; la biblioteca de C almacenaba las escrituras en búfer en partes de 4 KiB para reducir los desplazamientos repetidos. La parametrización histórica dejaba separaciones de rotación entre bloques consecutivos para que el siguiente bloque solicitado no hubiera pasado ya por el cabezal. Los búferes de pista modernos hacen innecesaria esa técnica al obtener una pista internamente.

Los nombres largos, los enlaces simbólicos y rename atómico eran capacidades adicionales de FFS. La mejora de velocidad debida a la organización no exigía cambiar los programas existentes.

Una adición al final de un archivo parece una sola acción para un programa. En el disco modifica varias estructuras y un fallo puede dejar solo algunas actualizadas. La consistencia ante fallos plantea cómo prevenir o reparar esos resultados parciales.

Sigue tres escrituras independientes

Añadir un bloque de 4 KiB al final de un archivo existente modifica:

• Db, el nuevo bloque de datos que contiene los bytes añadidos.
• I, el inodo con un tamaño mayor y un puntero a ese bloque.
• B, el mapa de bits de datos que marca el bloque como asignado.

Si los tres llegan al almacenamiento, se obtiene la actualización consistente prevista. Si no llega ninguno, se conserva el estado antiguo consistente. El peligro está en las seis combinaciones parciales. El dispositivo puede reordenar las solicitudes, por lo que enviarlas en un orden determinado sin esperar no establece el orden en que se completan.

Clasifica cada resultado parcial

Se produce una inconsistencia cuando los metadatos no concuerdan, por ejemplo, cuando un inodo reclama un bloque cuyo bit de asignación indica que está libre. El asignador podría entonces dar ese mismo bloque a otro archivo. Una fuga de espacio de almacenamiento reserva espacio al que ningún archivo puede acceder. Los datos basura pueden ser más difíciles de detectar: I y B concuerdan perfectamente aunque Db nunca llegó.

Db por sí solo no provoca una fuga de espacio asignado, porque el mapa de bits sigue permitiendo reutilizar ese bloque. Escribir bytes en una ubicación libre no equivale a asignarla. B por sí solo sí provoca una fuga de espacio, porque la asignación sobrevivió sin un puntero propietario.

Separa estructura y significado

Un comprobador puede comparar punteros con mapas de bits. En general, no puede saber si unos bytes aparentemente válidos son los que un programa pretendía guardar. El resultado I y B demuestra este límite: un archivo estructuralmente válido puede tener contenido incorrecto.

La transición deseada es atómica para toda la actualización: recuperar el estado antiguo completo o el nuevo completo. Un modelo sencillo de almacenamiento solo proporciona escrituras atómicas para un sector, tradicionalmente de 512 bytes. Varios bloques del sistema de archivos superan esa unidad, por lo que el sistema de archivos debe construir un protocolo más sólido. Las garantías reales de escritura atómica dependen del dispositivo y de la interfaz; el protocolo del diario debe hacer que su registro de confirmación quepa en la unidad atómica admitida.

El almacenamiento en búfer aumenta el número de cambios que pueden perderse, pero no es la causa de fondo. Incluso enviar inmediatamente cada escritura deja un punto posible de fallo entre dos finalizaciones distintas. La creación, el cambio de nombre y la eliminación de archivos también modifican varias estructuras. Para comprender sus estados de fallo se empieza con el mismo ejercicio: identificar cada bloque modificado y preguntarse qué ocurre cuando solo sobrevive un subconjunto.

Un comprobador de sistemas de archivos repara las relaciones entre las estructuras almacenadas después de que se produzcan daños. Su ventaja es una visión amplia de los metadatos; sus debilidades son el coste de explorarlos y el desconocimiento del contenido previsto de los archivos.

Reconstruye el estado de la asignación

fsck examina un sistema de archivos que no se cerró correctamente antes de montarlo de forma normal. Comprueba si el tamaño y los recuentos del superbloque son razonables y puede usar una copia de respaldo si la principal está dañada.

Después examina inodos y bloques indirectos para determinar a qué bloques de datos apuntan realmente los archivos. A partir de esa información de propiedad reconstruye los mapas de bits de asignación. Si un inodo por lo demás válido apunta al bloque 74 mientras el mapa de bits indica que el 74 está libre, el mapa debe cambiar para marcarlo como asignado. Confiar solo en el mapa de bits podría permitir que una asignación posterior sobrescribiera los datos del archivo.

La discrepancia opuesta es un bit del mapa marcado como asignado sin un puntero de inodo propietario. Reconstruir el mapa puede recuperar ese espacio. La reparación establece una relación consistente; no puede reconstruir bytes arbitrarios de la aplicación que falten.

Comprueba objetos, nombres y enlaces

Todo inodo asignado necesita un tipo válido, como archivo normal, directorio o enlace simbólico. Un inodo que no se puede reparar se borra y se ajustan los registros de asignación.

Recorrer desde la raíz permite a fsck contar las referencias de directorio a cada inodo. Compara estas referencias observadas con los números de enlaces registrados y corrige los errores. Un inodo asignado al que ningún directorio llega puede trasladarse a lost+found, lo que da al contenido recuperado un nombre accesible sin conocer su ruta original.

Otras comprobaciones incluyen:

• Propiedad duplicada: dos inodos reclaman un bloque de datos. Una reparación puede borrar uno de los inodos o dar a cada archivo una copia separada.
• Direcciones no válidas: deben borrarse los punteros fuera del intervalo válido del sistema de archivos.
• Estructura de directorios: . y .. deben ser válidas y ocupar las primeras entradas en la organización sencilla de directorios, las entradas deben referirse a inodos asignados y los directorios no deben tener varios padres.

Estas comprobaciones interactúan. Borrar un inodo no válido también cambia qué bloques deben estar asignados y qué entradas de directorio siguen siendo válidas. Por tanto, una reparación necesita una visión coherente de los metadatos, no solo una lista de bits individuales sospechosos.

Comprende qué demuestra un resultado sin errores

Supón que el inodo y el mapa de bits de una adición llegaron al disco, pero sus datos no. El puntero está dentro del intervalo válido, el bit de asignación está activado y la estructura de enlaces es válida. fsck no tiene ninguna discrepancia de metadatos que reparar. El archivo puede superar la comprobación mientras contiene bytes antiguos en la región recién añadida.

El tiempo de ejecución también depende principalmente del tamaño del sistema de archivos, no de la cantidad modificada antes de un fallo. Un fallo durante una actualización de tres bloques puede seguir requiriendo la exploración de todos los metadatos. En un sistema de archivos grande esto puede tardar entre minutos y horas, durante las cuales el acceso normal no está disponible.

El registro en diario reduce el trabajo habitual de recuperación tras un fallo al registrar las actualizaciones recientes. No hace que un comprobador quede obsoleto: los errores de software o los fallos de hardware pueden dañar estructuras más allá de lo que puede reparar la reaplicación del diario. fsck sigue siendo una herramienta de reparación para esos casos.

Un diario registra una actualización antes de que el sistema de archivos sobrescriba sus ubicaciones habituales. Después de un fallo, ese registro indica a la recuperación qué cambios completos pueden rehacerse. Esto es el registro anticipado. Ext3, ext4, XFS y NTFS usan registro en diario, aunque sus formatos exactos de registro difieren.

Describe una actualización como una transacción

Para una adición al final de un archivo, el registro de datos en diario registra copias del nuevo inodo I, del mapa de bits B y del bloque de datos Db. Un registro de inicio de transacción, TxB, lleva un identificador y los destinos finales de los bloques. Un registro de fin de transacción, TxE, lleva el identificador correspondiente y marca la confirmación.

Registrar imágenes completas de los bloques de sustitución es registro físico. Registrar en su lugar una descripción de la operación es registro lógico. Rehacer físicamente tiene una propiedad útil: volver a escribir la misma imagen en la misma dirección tiene el mismo efecto. Por tanto, la recuperación puede repetir un punto de control que se completó parcialmente antes del fallo.

Sitúa la confirmación después del contenido

El protocolo básico tiene cuatro etapas:

1. Escritura en el diario: escribir TxB, I, B y Db en el diario y esperar a que la escritura duradera se complete.
2. Confirmación: escribir TxE y esperar. La transacción queda confirmada.
3. Punto de control: copiar I, B y Db del diario a sus ubicaciones finales.
4. Liberación: liberar el espacio del diario de esa transacción para reutilizarlo más adelante.

TxE no debe hacerse duradero antes que su contenido. Si se enviaran los cinco bloques sin una garantía de orden, un dispositivo podría completar TxB y TxE y dejar Db sin escribir. La recuperación confundiría una transacción incompleta con una válida. En el modelo básico, TxE cabe en una escritura atómica de sector, por lo que está presente como registro de confirmación completo o está ausente.

Las cachés de escritura del dispositivo también deben respetar el límite de durabilidad. Los vaciados de caché o las escrituras forzadas impiden que una caché volátil del dispositivo haga creer al protocolo que el contenido está a salvo cuando un corte de energía aún podría borrarlo.

Recupérate de dos puntos de fallo

Un fallo después del contenido, pero antes de TxE, deja una transacción sin confirmar. La recuperación la ignora y conserva el estado antiguo del archivo.

Un fallo después de TxE, pero durante el establecimiento del punto de control, deja una transacción confirmada. La recuperación escribe todas sus imágenes en sus ubicaciones finales en orden. Algunas escrituras pueden repetir trabajo ya realizado, lo que no causa problemas para estas imágenes de bloques. Esto es la recuperación mediante rehacer. El espacio del diario no puede reutilizarse hasta que las imágenes confirmadas hayan llegado a sus ubicaciones finales.

El diario es un registro circular. Su superbloque registra el intervalo activo, lo que permite reutilizar el espacio completado. Agrupar varias actualizaciones en una transacción puede registrar una sola vez un bloque de directorio o un mapa de bits compartido. El intervalo de confirmación predeterminado de ext4 es de 5 segundos, por lo que la confirmación no es automáticamente inmediata después de cada escritura de una aplicación.

Distingue las sumas de comprobación de la durabilidad

Una suma de comprobación de transacción puede revelar bloques de contenido ausentes o escritos de forma incompleta incluso cuando hay un registro de confirmación. Un protocolo basado en sumas de comprobación puede enviar juntas las escrituras del diario y aceptar solo las transacciones cuya validación tiene éxito. Las sumas de comprobación detectan registros incompletos; los vaciados de caché establecen si los bytes cuya escritura se ha reconocido sobreviven realmente.

Una escritura de una aplicación que permanece en búfer y sin confirmar aún puede desaparecer. Un programa que requiere una finalización duradera usa fsync y comprueba que termine correctamente.

El registro de datos en diario escribe el contenido de los archivos en el diario y después en sus ubicaciones finales. Registrar solo los metadatos reduce ese tráfico, pero el orden entre los datos y los metadatos sigue determinando lo que puede mostrar la recuperación.

Mantén los datos por delante de los punteros confirmados

En el registro ordenado de metadatos en diario, Db va directamente a su ubicación final. TxB, I y B van al diario. Estos dos conjuntos de escrituras pueden ejecutarse en paralelo, pero ambos deben terminar antes de que TxE confirme los metadatos. Después de la confirmación, I y B pueden escribirse en sus ubicaciones finales y puede liberarse el espacio del diario.

La dependencia es la clave: el bloque que indica un puntero debe estar listo antes de que ese puntero pueda recuperarse. Si I se confirma primero, la recuperación puede instalar un puntero válido a bytes dejados por un usuario anterior del bloque. Los metadatos concordarían sin contener los datos previstos.

El modo ordenado es el predeterminado. El registro de metadatos en diario por sí solo no implica el modo ordenado: el modo de escritura diferida puede recuperar archivos estructuralmente correctos con contenido desactualizado. El modo de registro de datos ilustra el protocolo completo, pero supone una segunda escritura de los datos del archivo.

Evita que la reaplicación dañe un bloque reutilizado

El contenido de los directorios cuenta como metadatos. Supón que se registra un bloque de directorio en la dirección 1000, después se elimina el directorio y la misma dirección pasa a contener datos de un archivo normal. Esos nuevos datos de usuario no se registran en el modo de solo metadatos. Reaplicar la imagen antigua del directorio después de un fallo sobrescribiría los bytes del nuevo archivo.

Un registro de revocación confirmado indica a la recuperación que omita las copias registradas de ese bloque en transacciones anteriores a la revocación o en la propia transacción que la contiene. No prohíbe todos los usos futuros de la dirección. Si una transacción posterior vuelve a registrar ese bloque, la imagen posterior aún puede reaplicarse. Este límite temporal distingue la revocación de marcar permanentemente un bloque como inutilizable.

Compara alternativas

Las actualizaciones suaves imponen dependencias entre escrituras ordinarias sin un diario. Escribir datos inicializados antes de un puntero evita que se pueda acceder a datos basura, aunque las operaciones interrumpidas pueden provocar fugas de espacio que una comprobación posterior en segundo plano recupera. FFS de FreeBSD usa este enfoque. Seguir todas las dependencias dificulta la implementación.

La copia en escritura (COW) escribe los bloques modificados en ubicaciones sin usar y cambia atómicamente un puntero raíz para publicar el nuevo árbol. El árbol antiguo permanece disponible hasta el cambio. ZFS, Btrfs y WAFL usan diseños relacionados; conservar los bloques antiguos también permite crear instantáneas.

Los diseños de investigación basados en punteros inversos registran la propiedad desde los datos hacia los inodos para que las actualizaciones incompletas dejen discrepancias detectables. La consistencia optimista ante fallos reduce las esperas y usa sumas de comprobación y otras comprobaciones para detectar trabajo incompleto. Cada enfoque equilibra el tráfico de escritura, las garantías de recuperación y la complejidad de implementación. El registro ordenado de metadatos en diario mantiene breve la recuperación y escribe una sola vez los datos de archivos ordinarios.

Un sistema de archivos estructurado como registro convierte pequeñas actualizaciones dispersas en grandes escrituras secuenciales. Esto ayuda a un disco cuya tasa de transferencia es alta, pero cuyas demoras de búsqueda y rotación siguen siendo costosas.

Reúne las actualizaciones en un segmento

LFS de Berkeley, desarrollado por Rosenblum y Ousterhout y publicado en 1991, partió de la evolución de las cargas de trabajo. Las memorias más grandes atendían más lecturas desde la caché, por lo que las escrituras representaban una parte mayor del tráfico de disco. El ancho de banda secuencial crecía más rápido que la velocidad de posicionamiento. FFS seguía necesitando varias escrituras cortas de metadatos y datos para crear un archivo pequeño, y las escrituras pequeñas también funcionaban mal con RAID con paridad.

LFS almacena juntos en búfer en memoria los datos modificados, los inodos y la información de correspondencia. Los escribe en una región del disco sin usar como un gran segmento. Actualizar un bloque crea una nueva versión en una dirección nueva; la versión anterior permanece físicamente hasta que la limpieza recupera su segmento.

Los segmentos amortizan el posicionamiento igual que los fragmentos grandes de FFS. Con una tasa R, un tiempo de posicionamiento T y una fracción deseada del tiempo de transferencia F, el tamaño almacenado en búfer es:

A 200 MB/s y 5 ms, el 95 % requiere 19 MB. La transferencia tarda 95 ms, el posicionamiento tarda 5 ms y la tasa efectiva es 19 MB por 0,1 s = 190 MB/s. Una fracción objetivo alta puede requerir un segmento mayor que los habituales, de cientos de kilobytes a varios megabytes. El tamaño necesario depende del dispositivo y del objetivo, no de la palabra «segmento».

Encuentra un inodo que sigue moviéndose

La fórmula de la tabla fija de inodos ya no funciona: cada actualización de un inodo lo escribe en una dirección nueva. LFS añade un mapa de inodos, o imap, que relaciona cada número de inodo con su dirección de disco más reciente. Las partes actualizadas del imap se escriben en el registro junto a los inodos que describen.

Una región de puntos de control (CR) fija registra dónde están las partes más recientes del imap. Se actualiza periódicamente, por ejemplo cada 30 segundos, para que la escritura ocasional en una ubicación fija no domine el tráfico.

La cadena de búsqueda es:

1. Leer la CR al montar para encontrar las partes actuales del imap.
2. Cargar el imap en memoria.
3. Buscar en el imap el número de inodo solicitado.
4. Leer ese inodo más reciente y seguir sus punteros a datos.

Una vez que el imap está en caché, las lecturas ordinarias de archivos usan prácticamente la misma ruta de inodo a datos que en FFS. La correspondencia adicional hace viable el movimiento sin cambiar la identidad estable del archivo.

Mantén estables las entradas de directorio

Un directorio almacena nombres y números de inodo. Si se actualiza /docs/report.txt, su inodo se mueve, pero conserva su número. El imap cambia; la entrada de directorio no necesita cambiar solo por ese movimiento.

Sin esta indirección, un directorio que contuviera direcciones físicas de inodos tendría que reescribirse cada vez que se moviera un inodo hijo. Su propio inodo se movería entonces, lo que obligaría a cambiar su directorio padre, y así sucesivamente hacia la raíz. El imap interrumpe este problema de actualización recursiva.

LFS hace secuenciales las escrituras, pero no todas las lecturas. Los bloques sin cambios de un archivo pueden permanecer en segmentos antiguos mientras las versiones posteriores de otros bloques se mueven a otros lugares. Leer ese archivo aún puede requerir búsquedas entre segmentos; las grandes cachés de memoria forman parte de la motivación del diseño.

Escribir nuevas versiones en ubicaciones sin usar mantiene físicamente presentes los bytes antiguos. LFS necesita distinguir las versiones antiguas inaccesibles de los bloques vigentes, recuperar grandes regiones libres y recuperar una correspondencia utilizable después de un fallo.

Limpia segmentos completos

El limpiador de segmentos lee segmentos ocupados parcialmente, copia sus bloques vigentes en un número menor de segmentos nuevos y libera los segmentos antiguos. Si cuatro segmentos del mismo tamaño tienen cada uno una cuarta parte de datos vigentes, sus datos vigentes combinados llenan un segmento nuevo. Liberar los cuatro segmentos antiguos después de la copia gana tres segmentos de capacidad utilizable.

Limpiar segmentos completos conserva grandes regiones contiguas para futuras escrituras secuenciales. La copia tiene un coste: los bloques vigentes se leen y escriben de nuevo aunque ninguna aplicación los haya cambiado. Un disco casi lleno con segmentos mayoritariamente vigentes puede requerir mucha copia para recuperar poco espacio libre.

Determina si un bloque está vigente

Un resumen de segmento identifica el inodo propietario de cada bloque y su desplazamiento de bloque lógico dentro del archivo. Para comprobar un bloque en la dirección A, usa el imap para encontrar el inodo más reciente de ese propietario. Sigue su puntero para el bloque lógico registrado. Si el puntero sigue siendo igual a A, esta es la versión vigente. Si apunta a otro lugar, A está obsoleto.

Por ejemplo, un resumen asocia la dirección 600 con el inodo 14, bloque lógico 2. El inodo 14 actual apunta para el bloque lógico 2 a la dirección 920. El bloque 600 ya no está vigente aunque sus bytes parezcan datos válidos. La vigencia depende de la accesibilidad actual, no de cuán recientemente se escribió un bloque ni de si su contenido parece útil.

Los números de versión aceleran el descarte. Eliminar un archivo o truncarlo a cero incrementa su versión en el imap. Un bloque de segmento con una versión anterior puede clasificarse como no vigente sin leer el inodo.

La política de limpieza también tiene en cuenta los cambios previstos. Los segmentos de actualización frecuente contienen bloques que se sobrescriben a menudo; esperar puede hacer que más bloques dejen de estar vigentes sin copiarlos. Los segmentos de actualización poco frecuente cambian poco, por lo que la política original de LFS los limpia antes. La política debe equilibrar la fracción vigente, la antigüedad y el espacio disponible; la frecuencia de actualización de un segmento por sí sola no mide el coste inmediato de copia.

Recupera la correspondencia y el trabajo reciente

LFS mantiene dos regiones de puntos de control en extremos opuestos del disco y alterna las actualizaciones. Cada actualización escribe una cabecera con marca de tiempo, el cuerpo y una marca de tiempo final coincidente. La recuperación elige la región más reciente cuyo principio y final coinciden. Una actualización más reciente interrumpida no sustituye a un punto de control completo anterior.

El punto de control puede no incluir los segmentos completados más recientes. Por ello, la recuperación avanza desde el final del registro que tiene anotado, busca actualizaciones válidas posteriores y las aplica para reconstruir la correspondencia actual. Los datos que nunca formaron una actualización válida recuperable no pueden recrearse desde la memoria después de un corte de energía.

Los sistemas relacionados con copia en escritura conservan bloques antiguos para permitir instantáneas; ZFS, Btrfs y WAFL comparten esa idea general. Los controladores de unidades SSD suelen usar capas de traducción de memoria flash estructuradas como registro, mientras que F2FS aplica ideas de estructura como registro a nivel de sistema de archivos para almacenamiento flash. Cada uno sigue necesitando una forma de recuperar el espacio que dejan las versiones obsoletas.

Un sistema de archivos distribuido mantiene archivos en un servidor mientras los programas de las máquinas cliente usan las llamadas de archivo habituales. El cliente traduce esas llamadas en solicitudes de red. Las demoras y los fallos plantean una pregunta que las llamadas locales suelen ocultar: ¿qué debe hacer un cliente cuando no puede saber si una solicitud se completó?

Mantén el estado de los archivos abiertos en el cliente

El sistema de archivos de red (NFS) de Sun comenzó en la década de 1980. NFSv2 hizo que su servidor no mantuviera estado respecto a los archivos abiertos. El servidor almacena archivos, pero no recuerda los descriptores ni los desplazamientos actuales de cada cliente. Cada solicitud lleva suficiente información para ejecutarse sin una solicitud de apertura anterior.

Un identificador de archivo remoto identifica el volumen del servidor, el número de inodo y la generación del inodo. La generación cambia cuando se reutiliza un número de inodo, lo que impide que un identificador antiguo nombre accidentalmente otro archivo en esa posición reutilizada.

Para abrir /home/ana/notes.txt, el cliente parte de un identificador de la raíz y envía LOOKUP para home, ana y notes.txt. Conserva el identificador resultante en su propio estado de archivos abiertos. Leer los primeros 4 KiB se convierte en una solicitud READ que contiene ese identificador, el desplazamiento 0 y la cantidad 4096. Cerrar el descriptor local no necesita una solicitud CLOSE de NFSv2 porque el servidor no tiene ninguna entrada de archivo abierto que liberar.

Reintenta sin repetir un efecto

Si no llega una respuesta, el cliente no puede distinguir entre una solicitud perdida, un servidor no disponible o una respuesta perdida. Vuelve a enviar la solicitud cuando se agota el tiempo de espera.

Una operación es idempotente cuando repetirla tiene el mismo efecto que ejecutarla una vez. READ, LOOKUP y GETATTR no modifican el contenido almacenado. En este modelo, una operación WRITE con desplazamiento explícito también repite de forma segura los mismos bytes en la misma ubicación. Repetir una solicitud que diga «añade estos bytes al final actual» añadiría, en cambio, una segunda copia; el desplazamiento de un WRITE de NFS evita esa ambigüedad.

Algunas solicitudes necesitan más cuidado. Reintentar un MKDIR que tuvo éxito después de perderse su respuesta puede devolver «ya existe». El directorio está presente, pero la respuesta repetida difiere del éxito original. La recuperación sin estado no convierte todas las operaciones en solicitudes fáciles de repetir.

Haz fiables las confirmaciones de recepción

NFSv2 debe hacer duradero un WRITE antes de confirmar su éxito. De lo contrario, el servidor podría confirmar un bloque, perderlo de la memoria durante un fallo y después aceptar bloques posteriores. El cliente creería que todas las escrituras tuvieron éxito mientras el archivo carecería de una actualización intermedia.

Las respuestas después del almacenamiento estable evitan ese fallo a costa del rendimiento. NFSv3 añadió escrituras no estables seguidas de COMMIT, lo que permite hacer duraderas varias escrituras conjuntamente. El cliente debe distinguir una confirmación no estable de una finalización duradera.

Distingue las versiones del protocolo

Un protocolo con estado necesita mecanismos para recuperar el estado de archivos abiertos y bloqueos después de reiniciar un servidor y liberar el estado de los clientes que fallaron. NFSv4 acepta deliberadamente esa complejidad: tiene OPEN, CLOSE, bloqueos y concesiones temporales que los clientes renuevan. El cliente de Linux normalmente prueba primero la versión 4.2 y recurre a otras cuando es necesario. Por tanto, afirmar que NFSv2 no mantiene estado no describe todas las versiones de NFS.

La caché del cliente ahorra viajes por la red, pero crea varias copias de los archivos compartidos. La regla de consistencia determina cuándo otra máquina debe dejar de usar una copia antigua y obtener los cambios del escritor.

Valida las cachés de NFS en los límites de compartición

Según la consistencia de cierre a apertura de NFS, cerrar un archivo modificado envía las escrituras almacenadas en búfer al servidor. Una apertura posterior en otro cliente comprueba que la copia esté actualizada y ve esos cambios. GETATTR o una validación relacionada compara los atributos del servidor con los almacenados en caché y descarta los datos desactualizados cuando detecta un cambio.

Comprobar en cada acceso sobrecargaría el servidor. Linux almacena en caché los atributos de archivos normales durante intervalos predeterminados de entre 3 y 60 segundos. Por tanto, un proceso que mantiene abierto un archivo puede leer datos de caché desactualizados entre comprobaciones. La apertura es un límite de compartición más sólido que una lectura cualquiera mediante un descriptor ya abierto. El comportamiento de cierre a apertura no garantiza la visibilidad inmediata de cada escritura individual.

Reutiliza archivos completos con los compromisos de notificación de AFS

El sistema de archivos Andrew (AFS) se diseñó en Carnegie Mellon en la década de 1980 para admitir muchos clientes por servidor. Cuando no existe una copia local válida, la apertura obtiene el archivo completo y lo guarda en el disco local. Las lecturas y escrituras usan después esa copia, y cerrar un archivo modificado envía la nueva versión completa al servidor. Una copia válida en caché puede volver a abrirse sin descargarla de nuevo.

AFSv1 comprobaba la validez en cada apertura y dejaba el recorrido de rutas al servidor. AFSv2 trasladó el recorrido a los clientes, que almacenan directorios en caché, e introdujo compromisos de notificación de cambios. El servidor promete avisar a un cliente cuando cambie un objeto en caché. Hasta que se invalida esa promesa, el cliente reutiliza su copia sin comprobaciones repetidas. Su identificador de archivo incluye un volumen, un identificador de archivo y un identificador de unicidad.

Sigue dos sesiones que se solapan

Supón que los clientes A y B abren un archivo. A cambia su copia local y la cierra, enviando la nueva versión al servidor. El servidor invalida los compromisos de notificación de los demás clientes. Una apertura posterior en B obtiene la nueva versión, pero la sesión que B ya tenía abierta conserva su copia existente hasta que se cierre y se vuelva a abrir.

Si ambas máquinas modifican sus copias, la última en cerrar sustituye el archivo completo del servidor. Los bloques de las dos copias no se mezclan. Dos ediciones en desplazamientos distintos pueden perder los cambios de un cliente porque la prevalencia del último cierre elige una versión completa. Los procesos de una misma máquina cliente ven inmediatamente las escrituras de los demás.

Los compromisos de notificación son estado del servidor. Después de reiniciar un cliente, los archivos en caché son sospechosos porque pueden haberse perdido notificaciones. Después de reiniciar un servidor, los clientes deben detectar la pérdida de las promesas de notificación, mediante mensajes periódicos de comprobación o un aviso del servidor, y volver a validarlas.

Adapta la caché a la carga de trabajo

AFS también ofrecía un espacio de nombres global, listas de control de acceso y volúmenes gestionados por el administrador. Históricamente, AFSv2 aumentó la capacidad de un servidor a unos 50 clientes frente a los aproximadamente 20 de AFSv1. La regla de caché de ninguno de los dos diseños sustituye la coordinación explícita, como los bloqueos de archivo, cuando los programas necesitan actualizaciones compartidas seguras.