Sistemas Operativos Sistemas de archivos

Gunnar Wolf
26 de julio de 2013

ndice
1. Introduccin

2. Concepto de archivo
2.1. Operaciones con archivos . . . . . . . . . . . .
2.2. Tablas de archivos abiertos . . . . . . . . . . .
2.3. Acceso concurrente: Bloqueo de archivos . . . .
2.4. Tipos de archivo . . . . . . . . . . . . . . . . .
2.5. Estructura de los archivos y mtodos de acceso
2.6. Transferencias orientadas a bloques . . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

4
4
5
6
7
10
12

3. Organizacin de archivos
3.1. Evolucin del concepto de directorio
3.2. Operaciones con directorios . . . . .
3.3. Montaje de directorios . . . . . . . .
3.4. Sistemas de archivos remotos . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

13
13
18
20
23

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

4. Plasmando la estructura en el dispositivo

27
4.1. Diferentes sistemas de archivos . . . . . . . . . . . . . . . . . . . 28
4.2. El volumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3. El directorio y los i-nodos . . . . . . . . . . . . . . . . . . . . . . 30
5. Esquemas de asignacin de espacio
5.1. Asignacin contigua . . . . . . . .
5.2. Asignacin ligada . . . . . . . . . .
5.3. Asignacin indexada . . . . . . . .
5.4. Las tablas en FAT . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

34
34
35
36
39

6. Fallos y recuperacin
41
6.1. Datos y metadatos . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2. Verificacin de la integridad . . . . . . . . . . . . . . . . . . . . . 43
6.3. Actualizaciones suaves (soft updates) . . . . . . . . . . . . . . . . 44
6.4. Sistemas de archivo con bitcora (journaling file systems) . . . . 45
6.5. Sistemas de archivos estructurados en bitcora (log-structured file
systems) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
1

7. El medio fsico
47
7.1. Discos magnticos rotativos . . . . . . . . . . . . . . . . . . . . . 47
7.2. Almacenamiento en estado slido . . . . . . . . . . . . . . . . . . 54
8. Manejo avanzado de volmenes
8.1. RAID 0: Divisin en franjas . . . . . . .
8.2. RAID 1: Espejo . . . . . . . . . . . . . .
8.3. Los niveles 2, 3 y 4 de RAID . . . . . .
8.4. RAID 5: Paridad dividida por bloques .
8.5. RAID 6: Paridad por redundancia P+Q
8.6. Niveles combinados de RAID . . . . . .
8.7. Ms all de RAID . . . . . . . . . . . .
9. Otros recursos

1.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

57
57
58
59
59
60
61
62
63

Introduccin

De los roles que cumple el sistema operativo, probablemente el que ms

consciente tengan en general sus usuarios es el de la gestin del espacio de almacenamiento, esto es, el sistema de archivos. Al da de hoy, todos los usuarios
de equipo de cmputo dan por sentado y comprenden a grandes rasgos la organizacin del espacio de almacenamiento en un directorio jerrquico, con unidades
de almacenamiento llamadas archivos, de diferentes tipos segn su funcin. En
la primer parte de esta unidad revisaremos algo ms a profundidad a este modelo, para posteriormente ver los detalles de la gestin del espacio fsico donde
stos estn alojados.
La abstraccin que hoy conocemos como sistemas de archivos es una de las
que ms tiempo han vivido y se han mantenido a lo largo de la historia de la
computacin, sobreviviendo a lo largo de prcticamente todas las generaciones
de sistemas operativos. Sin embargo, para poder analizar cmo es que el sistema operativo representa la informacin en el dispositivo fsico, comenzaremos
discutiendo cmo es que esta informacin es comprendida por los niveles ms
altos Por los programas en espacio de usuario.
La informacin cruda tiene que pasar una serie de transformaciones. Yendo
de niveles superiores a niveles ms bajos, un programa estructura sus datos en
archivos, siguiendo el formato que resulte mas pertinente al tipo de informacin
a representar. Un conjunto de archivos hoy en da es tpicamente representado
en una estructura de directorios, y aunque existen otros mecanismos para su
organizacin, estos no estn tan ampliamente difundidos. Y cuando un sistema
opera con ms de un dispositivo fsico, encontraremos principalmente dos mecanismos para integrar a dichos dispositivos en un sistema de archivos virtual,
brindnado al usuario una interfaz uniforme. Por ltimo, los archivos son una
estructura meramente lgica Deben ser convertidos para ser representados

Figura 1: Capas de abstraccin para implementar los sistemas de archivos

en un dispositivo orientado a bloques como los diversos tipos de unidades que
conocemos aunque esta nomenclatura es a veces incorrecta como discos.
Del diagrama presentado, pues, toca al objeto de nuestro estudio el sistema
operativo recibir del espacio de usuario las llamadas al sistema que presentan
la interfaz de archivos y directorios, integrar el sistema de archivos virtual, y
traducir la informacin resultante a un sistema de archivos.
Cabe mencionar que varias de las capas aqu presentadas podran perfectamente ser subdivididas, analizadas por separado, e incluso tratarse de forma
completamente modular De hecho, este es precisamente el modo en que se
implementan de forma transparente caractersticas hoy en da tan comunes como sistemas de archivos en red, o compresin y cifrado de la informacin. Una
referencia ms detallada acerca de ventajas, desventajas, tcnicas y mecanismos de la divisin y comunicacin entre capas puede ubicarse en el artculo de
Heidemann y Popek (1994).
En esta unidad tocaremos tambin algunos conceptos relacionados con los
subsistemas de entrada y salida, aunque estos pertenecen mayormente a otras
unidades, al igual que los controladores.

2.

Concepto de archivo

En primer trmino, un archivo es un tipo de datos abstracto Esto es, en

programacin moderna podramos verlo como una estructura que exclusivamente permite que la manipulemos por medio de una interfaz orientada a objetos:
Los procesos en el sistema slo pueden tener acceso a los archivos por medio de
la interfaz ofrecida por el sistema operativo.1 Abordaremos los detalles de esta
interfaz en breve.
Para el usuario, los archivos son la unidad lgica mnima al hablar habla
de almacenamiento: Todo el almacenamiento persistente (que sobrevive en el
tiempo, sea a reinicios del sistema, a prdida de corriente o a otras circunstancias
en el transcurso normal de ejecucin) en el sistema al que tiene acceso, se efecta
dentro de archivos; el espacio libre en los diferentes dispositivos no tiene mayor
existencia fuera de saber que est potencialmente disponible.
Dentro de cada volmen (cada medio de almacenamiento), los archivos disponibles conforman a un directorio, y son tpicamente identificados por un nombre
o una ruta. Hablaremos ms adelante acerca de las diferentes construcciones
semnticas que pueden conformar a los directorios.

2.1.

Operaciones con archivos

Cada sistema operativo definir la interfaz de archivos acorde con su semntica, pero en lneas generales, las operaciones que siempre estarn disponibles
con un archivo son:
Crear Asigna espacio en el dispositivo y en su directorio para alojar a un nuevo
archivo.
Borrar Elimina al archivo del directorio y, de ser procedente, libera el espacio
del dispositivo
Abrir Solicita al sistema operativo verificar si tenemos el acceso para el modo
de acceso al archivo que indiquemos y si el medio lo soporta (por ejemplo,
a pesar de contar con los permisos, no podemos abrir para escritura un
archivo en un disco de slo lectura), y asigna un descriptor de archivos
que identifica la relacin entre el proceso y el archivo en cuestin. Abrir
un archivo es necesario para todas las siguientes operaciones.
Cerrar Indica al sistema que el proceso en cuestin termin de trabajar con
el archivo; el sistema entonces debe vaciar los buffers a disco y eliminar
la entrada que representa a esta combinacin archivo-proceso de las tablas activas, invalidando al descriptor de archivo. Si un proceso cierra un
archivo y quiere volver a emplearlo, tendr que abrirlo explcitamente.
1 Veremos ms adelante que esto no es necesariamente cierto, sin embargo, el uso de los
dispositivos en crudo es tan bajo que podemos ignorarlos para propsitos de esta discusin

Leer Cuando indicamos al sistema que queremos leer de un archivo hacia determinado buffer, ste copia el siguiente pedazo de informacin a ste. Este
pedazo podra ser una lnea o un bloque de longitud definida, dependiendo
del modo en que se solicite la lectura. El sistema mantiene un apuntador
a la ltima posicin leda, para poder continuar con la lectura.
Escribir Teniendo un archivo ya existente, guarda informacin en l. Puede ser
que escriba desde su primer posicin (truncando al archivo, esto es, borrando toda la informacin que pudiera ya tener), o agregando al archivo,
esto es, iniciando con el apuntador de escritura al final del mismo.
Reposicionar (seek ) Tanto la lectura como la escritura se hacen siguiendo a
un apuntador, que indica cul fue la ltima posicin del archivo a la que
acces el proceso actual. Al reposicionar el apuntador, podemos brincar a
otro punto del archivo.
Hay varias otras operaciones comunes que pueden implementarse con llamadas compuestas a estas operaciones (por ejemplo, copiar un archivo puede
implementarse como crear un archivo nuevo en modo de escritura, abrir en modo de lectura al fuente, e ir leyendo de ste y escribiendo al nuevo hasta llegar
al fin de archivo).
Las operaciones que presentamos recin no son todas las operaciones existentes; dependiendo del sistema operativo, habr algunas adicionales; estas las
presentamos como la base general sobre la cual trabajaremos.
Vale la pena mencionar que esta semntica para el manejo de archivos presenta a cada archivo como si fuera una unidad de cinta, permitindonos avanzar
o retroceder la cabeza lectora/escritora dentro de ella.

2.2.

Tablas de archivos abiertos

Tanto el sistema operativo como cada uno de los procesos mantienen normalmente tablas de archivos abiertos. Estas mantienen informacin acerca de todos
los archivos actualmente abiertos, presentndolos hacia el proceso por medio de
un descriptor de archivo; una vez que un archivo fue abierto, las operaciones que
se realizan dentro de ste no son empleando su nombre, sino que su descriptor
de archivos.
En un sistema operativo multitareas, ms de un proceso podra abrir el
mismo archivo a la vez; lo que cada uno de ellos pueda hacer, y cmo esto impacte
a lo que vean los dems procesos, depende de la semntica que implemente el
sistema.
Ahora, por qu mencionamos que estas tablas son mantenidas tanto por el
sistema operativo como por cada uno de los procesos? No nos lleva esto a una
situacin en que mantenemos informacin redundante?
La respuesta es que la informacin que cada uno debe manejar es distinta.
El sistema operativo necesita:
Conteo de usuarios del archivo Cuando se solicita, por ejemplo, desmontar una particin (por ejemplo, para expulsar una unidad removible) o
5

eliminar un archivo, el sistema debe poder determinar cundo es momento de declarar la solicitud como efectuada. Si algn proceso tiene abierto
a un archivo, y particularmente si tiene cambios pendientes de guardar, el
sistema no debe permitir que el archivo desaparezca de su visin.
Modos de acceso Aunque un usuario tenga permisos de acceso a determinado
recurso, el sistema puede determinar negarlo si llevara a una inconsistencia. Por ejemplo, si dos procesos abren un mismo archivo para escritura,
es probable que los cambios que realice uno sobreescriban a los que haga
el otro.
Ubicacin en disco Para evitar que cada proceso tenga que consultar las tablas en disco para encontrar al archivo, o sus fragmentos.
Informacin de bloqueo En caso de que los modos de acceso del archivo requieran proteccin mutua, puede implementarse por medio de un bloqueo.
Por otro lado, el proceso necesita:
Descriptor de archivo Relacin entre el nombre del archivo abierto y el identificador numrico que maneja internamente el proceso. Un archivo abierto
por varios procesos tendr descriptores de archivo distintos en cada uno
de ellos. El descriptor de archivo es un nmero entero.
Permisos Los modos vlidos de acceso para un archivo. Esto no necesariamente
es igual a los permisos que tiene el archivo en cuestin en disco, sino que
el subconjunto de dichos permisos bajo los cuales est operando para este
proceso en particular Si un archivo fue abierto en modo de slo lectura,
por ejemplo, este campo slo permitir la lectura.

2.3.

Acceso concurrente: Bloqueo de archivos

Dado que los archivos pueden emplearse como mecanismo de comunicacin

entre procesos que no guarden relacin entre s, incluso a lo largo del tiempo,
y para emplear un archivo basta indicar su nombre o ruta, los sistemas operativos multitarea implementan mecanismos de bloqueo para evitar que varios
procesos intentando emplear de forma concurrente a un archivo se corrompan
mutuamente.
Algunos sistemas operativos permiten establecer bloqueos sobre determinadas regiones de los archivos, aunque la semntica ms comn es operar sobre el
archivo como una sola unidad.
En general, la nomenclatura que se sigue para los bloqueos es:
Compartido (Shared lock ) Podra verse como equivalente a un bloqueo (o
candado) para realizar lectura Varios procesos pueden adquirir al mismo
tiempo un bloqueo de lectura, e indica que todos los que posean dicho
candado tienen la expectativa de que el archivo no sufrir modificaciones.

Exclusivo (Exclusive lock ) Un bloqueo o candado exclusivo puede ser adquirido

por un slo proceso, e indica que realizar operaciones que modifiquen al
archivo (o, si la semntica del sistema operativo permite expresarlo, a la
porcin del archivo que indica).
Respecto al mecanismo de bloqueo, hay tambin dos tipos, dependiendo de
qu tan explcito tiene que ser su manejo:
Mandatorio u obligatorio (Mandatory locking) Una vez que un proceso adquiere un candado obligatorio, el sistema operativo se encargar de imponer las restricciones corresponidentes de acceso a todos los dems procesos, independientemente de si stos fueron programados para considerar
la existencia de dicho bloqueo o no.
Consultivo o asesor (Advisory locking) Este tipo de bloqueos es manejado
exclusivamente entre los procesos involucrados, y depende del programador de cada uno de los programas en cuestin el solicitar y respetar dicho
bloqueo.
Haciendo un paralelo con los mecanismos presentados en la unidad de administracin de procesos, los mecanismos que emplean mutexes, semforos o
variables de condicin seran consultivos, y nicamente los que emplean monitores (en que la nica manera de llegar a la informacin es a travs del mecanismo
que la protege) seran mandatorios.
De esta matriz de 2 2 tipos de bloqueo, no todos los sistemas operativos implementan las cuatro posibilidaddes. Como regla general, en los sistemas
Windows se maneja un esquema de bloqueo obligatorio, y en sistemas Unix es
de bloqueo consultivo.2
Cabe mencionar que el manejo de bloqueos con archivos requiere del mismo
cuidado que el de bloqueo por recursos que el que vimos en administracin
de procesos: Dos procesos intentando adquirir un candado exclusivo sobre dos
archivos pueden caer en un bloqueo mutuo tal como ocurre con cualquier otro
recurso externo.

2.4.

Tipos de archivo

Si los archivos son, como dijimos, la unidad lgica mnima con la que se
puede guardar informacin en almacenamiento secundario, naturalmente sigue
que existen archivos de diferentes tipos Un archivo puede ser un documento
de texto, un binario ejecutable, un archivo de audio o video, y un largusimo
etcetera, e intentar emplear a un archivo como uno de un tipo distinto puede
2 Esto explica por qu en Windows es tan comn que el sistema mismo nos rechace hacer
determinada operacin porque el archivo est abierto por otro programa (bloqueo mandatorio
compartido), mientras que en Unix esta responsabilidad recae en cada uno de los programas
de aplicacin

resultar desde una frustracin al usuario porque el programa no responde como

ste quiere, hasta en prdidas econmicas.3
Hay tres estrategias principales para que el sistema operativo reconozca al
tipo de un archivo:
Extensin En los sistemas CP/M de los 1970, el nombre de cada archivo se
divida en dos porciones, empleando como separador al punto: El nombre
del archivo y su extensin. El sistema mantena una lista de extensiones
conocidas, para las cuales sabra cmo actuar, y este diseo se extendera
a las aplicaciones, que slo abriran a aquellos archivos cuyas extensiones
supieran manejar.
Esta estrategia fue heredada por VMS y MS-DOS, de donde la adopt
Windows; ya en el contexto de un entorno grfico, Windows agrega, ms
all de las extensiones directamente ejecutables, la relacin de extensiones
con los programas capaces de trabajar con ellas, permitiendo invocar a un
programa con slo dar doble click en un documento.
Como nota, este esquema de asociacin de tipo de archivo permite ocultar las extensiones toda vez que ya no requieren ser del conocimiento del
usuario, sino que son gestionadas por el sistema operativo, abre una va
de ataque automatizado que se populariz en su momento: El envo de
correos con extensiones engaosas duplicadas Esto es, el programa maligno (un programa troyano) se enva a todos los contactos del usuario
infectado, presentndose por ejemplo como una imgen, con el nombre
inocente.png.exe. Por el esquema de ocultamiento mencionado, ste
se presenta al usuario como inocente.png, pero al abrirlo, el sistema
operativo lo reconoce como un ejecutable, y lo ejecuta en vez de abrirlo
en un visor de imgenes.
Nmeros mgicos La alternativa que emplean los sistemas Unix es, como
siempre, simple y elegante, aunque indudablemente presenta eventuales
lagunas: El sistema mantiene una lista compilada de las huellas digitales
de los principales formatos que debe manejar,4 para reconocer el contenido
de un archivo basado en sus primeros bytes.
Casi todos los formatos de archivo incluyen lo necesario para que se lleve
a cabo este reconocimiento, y cuando no es posible hacerlo, se intenta
por medio de ciertas reglas heursticas. Por ejemplo, todos los archivos
de imgen en formato de intercambio grfico (GIF) inician con la cadena
GIF87a o GIF89a, dependiendo de la versin; los archivos del lenguaje
de descripcin de pginas PostScript inician con la cadena %!, el Formato
3 Por ejemplo, imprimir un archivo binario resulta en una gran cantidad de hojas intiles,
particularmente tomando en cuenta que hay caracteres de control como el ASCII 12 (avance
de forma, form feed), que llevan a las impresoras que operan en modo texto a iniciar una
nueva pgina; llevar a un usuario a correr un archivo ejecutable disfrazado de un documento
inocuo, como veremos a continuacin, fue un importante vector de infeccin de muchos virus.
4 Una de las ventajas de este esquema es que cada administrador de sistema puede ampliar
la lista con las huellas digitales que requiera localmente

de Documentos Porttiles (PDF) con %PDF, etctera. Un documento en

formatos definidos alrededor de XML inicia con <!DOCTYPE. Algunos de
estos formatos no estn anclados al inicio, sino que en un punto especfico
del primer bloque.
Un caso especial de nmeros mgicos es el llamado hashbang (#!). Esto indica a un sistema Unix que el archivo en cuestin (tpicamente un archivo de texto, incluyendo cdigo fuente en algn lenguaje de
script) debe tratarse como un ejecutable, y empleando como intrprete
al comando indicado inmediatamente despus del hashbang. Es por esto
que podemos ejecutar directamente, por ejemplo, los archivos que inician con #!/usr/bin/bash: El sistema operativo invoca al programa
/usr/bin/bash, y le especifica como argumento al archivo en cuestin.
Metadatos externos Los sistemas de archivos empleado por las Apple Macintosh desde 1984 separan en dos divisiones (forks) la informacin de
un archivo: Los datos que propiamente constituyen al archivo en cuestin
son la divisin de datos (data fork ), y la informacin acerca del archivo
se guardan en una estructura independiente llamada divisin de recursos
(resource fork ).
Esta idea result fundamental para varias de las caractersticas amigables
al usuario que present Macintosh desde su introduccin Particularmente, para presentar un entorno grfico que respondiera gilmente, sin
tener que buscar los datos base de una aplicacin dentro de un archivo
de mucho mayor tamao. La divisin de recursos cabe en pocos sectores
de disco, y si tomamos en cuenta que las primeras Macintosh funcionaban
nicamente con discos flexibles, el tiempo invertido en leer una lista de
iconos podra ser demasiada.
La divisin de recursos puede contener todo tipo de informacin; los programas ejecutables son los que le dan un mayor uso, dado que incluyen
desde los aspectos grficos (icono a mostrar para el archivo, ubicacin de la
ventana a ser abierta, etc.) hasta aspectos funcionales, como la traduccin
de sus cadenas al lenguaje particular del sistema en que est instalado.
Esta divisin permite una gran flexibilidad, dado que no es necesario tener
acceso al fuente del programa para crear traducciones y temas.
En el tema particular que en esta seccin nos concierne, la divisin de
recursos incluye un campo creador, que indica qu programa fue el que
cre al archivo, mismo que ser llamado en caso de que el usuario invoque
directamente al archivo.
Las versiones actuales de MacOS ya no emplean esta tcnica, sino que una
llamada appDirectory, para propsitos de esta discusin, la tcnica base
es la misma.

2.5.

Estructura de los archivos y mtodos de acceso

La razn principal de la existencia del sistema de archivos son los archivos.

Un archivo almacena informacin de algn tipo, estructurado o no estructurado.
La mayor parte de los sistemas operativos maneja nicamente archivos sin
estructura Cada aplicacin es responsable de preparar la informacin de
forma congruente, y la responsabilidad del sistema operativo es nicamente entregarlo como un conjunto de bytes. Ha habido sistemas de archivos histricos,
como IBM CICS (1968), IBM MVS (1974) o DEC VMS (1977), que administraban ciertos tipos de datos en un formato bsico de base de datos.
El que el sistema operativo no imponga estructura a un archivo no significa,
claro est, que la aplicacin que lo genera no lo haga. La razn por la que los
sistemas creados en los ltimos 30 aos no han implementado este esquema de
base de datos es que le resta flexibilidad al sistema: El que una aplicacin tuviera
que ceirse a los tipos de datos y alineacin de campos del sistema operativo
impeda su adecuacin, y el que la funcionalidad de un archivo tipo base de
datos dependiera de la versin del sistema operativo creaba un acoplamiento
demasiado rgido entre el sistema operativo y las aplicaciones: Hoy en da es
mucho ms comn ver que los programas que requieren gestores de base de datos
interacten con uno, implementado independientemente en espacio de usuario, o
incluso que liguen con un gestor implementado como biblioteca, como es el caso
de SQLite (que es empleado por herramientas de adquisicin de datos tan de
bajo nivel como systemtap, y por herramientas tan de escritorio como el gestor
de fotografas shotwell o el navegador Firefox ).
Podemos ver an un remanente de los archivos estructurados en los sistemas
derivados de MS-DOS: En estos sistemas, un archivo puede ser de texto o binario.
Un archivo de texto est compuesto por una serie de caracteres que forman
lneas, y la separacin entre una lnea y otra constituye de un retorno de carro
(CR, caracter ASCII 13) seguido de un salto de lnea (LF, caracter ASCII 10).5
El acceso a los archivos puede realizarse de diferentes maneras:
Acceso secuencial Mantiene la semntica por medio de la cual pudiramos
leer de nuestros archivos fuera la equivalente a unidad de cinta que mencionamos en la seccin Operaciones con archivos: El mecanismo principal
para leer o escribir es ir avanzando consecutivamente por los bloques que
conforman al archivo hasta llegar a su final.
Tpicamente emplearemos este mecanismo de lectura para leer a memoria
cdigo (programas o bibliotecas) o documentos, sea enteros o fracciones
de los mismos. Para un contenido estructurado, como una base de datos,
resultara absolutamente ineficiente, dado que no conocemos el punto de
5 Esta lgica es herencia de las mquinas de escribir manuales, en que el salto de lnea
(avanzar el rodillo a la lnea siguiente) era una operacin distinta a la del retorno de carro
(devolver la cabeza de escritura al inicio de la lnea). En la poca de los teletipos, como medida
para evitar que se perdieran caracteres mientras la cabeza volva hasta la izquierda, se decidi
separar el inicio de nueva lnea en los dos pasos que tienen las mquinas de escribir, para
inducir una demora que evitara la prdida de informacin.

10

inicio o finalizacin de cada uno de los registros, y probablemente tendramos que hacer barridos secuenciales del archivo completo para cada una
de las bsquedas.

Figura 2: Archivo de acceso secuencial

Acceso aleatorio El empleo de gestores como SQLite u otros muchos motores

de base de datos ms robustos no nos exime de pensar en nuestro archivo
como una tabla estructurada. Si la nica semntica por medio de la cual
pudiramos leer de nuestros archivos fuera la equivalente a una unidad de
cinta, implementar el acceso a un punto determinado del archivo podra
resultar demasiado gravoso.
Afortunadamente, el que el sistema operativo no imponga registros de
longitud fija no impide que el programa gestor lo haga. Si en el archivo al
cual apunta el descriptor de archivos FD tenemos 2000 registros de 75 bytes
cada uno y necesitamos recuperar el registro nmero 65 hacia el buffer
registro, reposicionamos el apuntador de lectura al byte 65 75 =
4875 (seek(FD, 4875)) y leemos los siguientes 75 bytes en registro
(read(FD, *registro, 75)).

Figura 3: Archivo de acceso aleatorio

Acceso relativo a ndice En los ltimos aos se han popularizado los gestores de base de datos no estructurados u orientados a texto, llamados genricamente NoSQL. Estos gestores pueden guardar registros de tamao
variable en disco, por lo que no podramos encontrar la ubicacin correcta
por medio de los mecanismos de acceso aleatorio.

11

Para implementar este acceso, se divide al conjunto de datos en dos secciones (incluso, posiblemente, en dos archivos independientes): La primer
seccin es una lista corta de identificadores, cada uno con el punto de inicio
y trmino de los datos a los que apunta. Para leer un registro, se emplea
acceso aleatorio sobre el ndice, y el apuntador se avanza a la ubicacin
especfica que se solicita.
En el transcurso de un uso intensivo de esta estructura, dado que la porcin
de ndice es muy frecuentemente consultada y relativamente muy pequea,
muy probablemente se mantenga completa en memoria, y el acceso a cada
uno de los registros puede resolverse en tiempo muy bajo.
La principal desventaja de este modelo de indexacin sobre registros de
longitud variable es que slo resulta eficiente para contenido mayormente
de lectura: Cada vez que se produce una escritura y cambia la longitud
de los datos almacenados, se va generando fragmentacin en el archivo, y
para resolverla probablemente se hace necesario suspender un tiempo la
ejecucin de todos los procesos que estn empleando al archivo en cuestin (e invalidar, claro, todas las copias en cach de los ndices). Ahora
bien, mientras se mantenga como mayormente de lectura, este formato
tendr la ventaja de no desperdiciar espacio en los campos nulos o de
valor irrelevante para algunos de los registros.
Adems de esto, la escritura en ambas partes de la base de datos debe
mantenerse con garantas de atomicidad Si se pierde la sincrona entre
ndice y datos, nos enfrentamos a una muy probable corrupcin de datos.

Figura 4: Acceso relativo a ndice: Un ndice apuntando al punto justo de un

archivo sin estructura

2.6.

Transferencias orientadas a bloques

Un sistema de archivos es la representacin que se da a un conjunto de

archivos y directorios sobre un dispositivo orientado a bloques; un dispositivo

12

orientado a bloques es uno que, para cualquier transferencia que solicitemos

desde o hacia l, nos responder con un bloque de tamao predefinido.
Esto es, si bien el sistema operativo nos presenta una abstraccin por medio
de la cual la lectura (read()) puede ser de un tamao arbitrario, todas las
transferencias de datos desde cualquiera de los discos sern de un mltiplo del
tamao de bloques, definido por el hardware (tpicamente 512 bytes).
Cuando leemos, como en el ejemplo anterior, slamente un registro de 75
bytes, el sistema operativo lee el bloque completo y probablemente lo mantiene
en un cach en la memoria principal; si en vez de una lectura, la operacin que
efectuamos fue una de escritura (write()), y el sector que vamos a modificar
no ha sido ledo an a memoria (o fue ledo hace mucho, y puede haber sido
expirado del cach), el sistema tendr que leerlo nuevamente, modificarlo en
memoria, y volver a guardarlo a disco.

3.

Organizacin de archivos

Hasta ahora, nos hemos enfocado en qu es y cmo se maneja un archivo.

Sin embargo, no hablaramos de sistemas de archivos si no tuviramos una gran
cantidad de archivos. Es comn que en un slo medio de almacenamiento de un
equipo de uso domstico tengamos a decenas de miles de archivos, y en equipos
dedicados, no est fuera de lugar tener cientos o miles de veces tanto. Por tanto,
tenemos que ver tambin cmo se organiza una gran cantidad de archivos.

3.1.

Evolucin del concepto de directorio

El concepto dominante en almacenaimiento hoy en da es el directorio jerrquico. Demos un breve repaso acerca de su historia.
3.1.1.

Convenciones de nomenclatura

Cada sistema de archivos puede determinar cuntos y qu caracteres son

vlidos para designar a uno de sus elementos, y cules son separadores vlidos.
El caracter que se emplea para separar los elementos de un directorio no es
un estndar a travs de todos los sistemas operativos Los ms comunes
que encontraremos hoy en da son la diagonal (/), empleada en sistemas tipo
Unix y derivados (incluyendo MacOS X y Android), y la diagonal invertida (\),
empleada en CP/M y derivados, incluyendo MS-DOS y Windows.
Diversos sistemas han manejado otros caracteres (por ejemplo, el MacOS histrico empleaba los dos puntos, :), y aunque muchas veces los mantenan ocultos del usuario a travs de una interfaz grfica rica, los programadores siempre
tuvieron que poder especificarlos.
A lo largo del presente texto manejaremos la diagonal (/) como separador
de directorios.

13

3.1.2.

Sistema de archivos plano

Los primeros sistemas de archivos limitaban el concepto de directorio a una

representacin plana de los archivos que lo conformaban, sin ningn concepto
de jerarqua de directorios como el que hoy nos es natural. Esto se deba, en
primer trmino, a lo limitado del espacio de almacenamiento de las primeras
computadoras en implementar esta metfora (los usuarios no dejaban sus archivos a largo plazo en el disco, sino que los tenan ah meramente cuando les eran
tiles), y en segundo trmino, a que no se haba an desarrollado un concepto
de separacin, permisos y privilegios como el que poco despus aparecera.
En las computadoras personales los sistemas de archivos eran tambin planos
en un primer momento, pero por otra razn: En los sistemas profesionales ya se
haba desarrollado el concepto; al aparecer la primer computadora personal en
1975, ya existan incluso las primeras versiones de Unix diseadas para trabajo
en red. La prioridad en los sistemas personales era mantener el cdigo del sistema
operativo simple, mnimo. Con unidades de disco capaces de manejar entre 80 y
160KB, no tena mucho sentido implementar directorios Si un usuario quisiera
llevar a cabo una divisin temtica de su trabajo, lo colocara en distintos discos
flexibles. El sistema operativo CP/M nunca soport jerarquas de directorios,
como tampoco lo hizo la primer versin de MS-DOS6 .
El sistema de archivos original de la Apple Macintosh, MFS, estaba construido sobre un modelo plano, pero presentando la ilusin de directorios de una
forma comparable a las etiquetas: Existan bajo ciertas vistas (pero notoriamente no en los dilogos de abrir y grabar archivos), pero el nombre de cada
uno de los archivos tena que ser nico, dado que el direcorio al que perteneca
era bsicamente slo un atributo del archivo.
Y contrario a lo que dicta la intuicin, el modelo de directorio plano no ha
desaparecido: El sistema de almacenamiento en la nube ofrecido por el servicio Amazon S3 (Simple Storage Service, Servicio Simple de Almacenamiento)
maneja nicamente objetos (comparable con nuestra definicin de archivos) y
cubetas (que reconoceramos como unidades o volmenes), y permite referirse a
un objeto o un conjunto de objetos basado en filtros sobre el total que conforman
a una cubeta.
Probablemente a futuro nos encontremos con ms ofertas como la de Amazon
S3, pero por ahora, continuemos sobre la lnea histrica de los directorios.
3.1.3.

Directorios de profundidad fija

Las primeras implementaciones de directorios eran de un slo nivel : El total

de archivos en un sistema poda estar dividido en directorios, fuera por tipo de
archivo (separando, por ejemplo, programas de sistema, programas de usuario y
textos del correo), por usuario (facilitando una separacin lgica de los archivos
de un usuario de pertenecientes a los dems usuarios del sistema)
6 el soporte de jerarquas de directorios fue introducido apenas en la versin 2, junto con el
soporte a discos duros de 10MB, con la IBM XT

14

El directorio raiz (base) se llama en este esquema MFD (Master File Directory, Directorio Maestro de Archivos), y cada uno de los directorios derivados
es un UFD (User File Directory, Directorio de Archivos de Usuario).

Figura 5: Directorio simple, limitado a un slo nivel de profundidad

Este esquema resuelve el problema principal del nombre global nico: Antes
de los directorios, cada usuario tena que cuidar que los nombres de sus archivos
fueran nicos en el sistema, y ya teniendo cada uno su propio espacio, se volvi
una tarea mucho ms simple. La desventaja es que, si el sistema restringe a cada
usuario a escribir en su UFD, se vuelve fundamentalmente imposible trabajar
en algn proyecto conjunto: No puede haber un directorio que est tanto dentro
de usr1 como de usr2, y los usuarios encontrarn ms dificil llevar un proyecto
conjunto.
3.1.4.

Directorios estructurados en rbol

El siguiente paso natural para este esquema es permitir una jerarqua ilimitada: En vez de exigir que exista una capa de directorios, se le puede dar
la vuelta al argumento, y permitir que cada directorio pueda contener a otros
archivos o directorios a niveles arbitrarios. Esto permite que cada usuario (y
que el administrador del sistema) estructure su informacin siguiendo criterios
lgicos y piense en el espacio de almacenamiento como un espacio a largo plazo.

Figura 6: Directorio estucturado en rbol

Junto con esta estructura nacen las rutas de bsqueda (search path): Tanto
los programas como las bibliotecas de sistema ahora pueden estar en cualquier
lugar del sistema de archivos. Al definirle al sistema una ruta de bsqueda, el

15

usuario operador puede desentenderse del lugar exacto en el que est determinado programa El sistema se encargar de buscar en todos los directorios
mencionados los programas o bibliotecas que ste requiera.7
3.1.5.

El directorio como un grafo dirigido

Si bien parecera que muchos de los sistemas de archivos que empleamos hoy
en da pueden modelarse suficientemente con un rbol, donde hay un slo nodo
raiz, y donde cada uno de los nodos tiene un slo nodo padre, la semntica que
ofrecen es en realidad un superconjunto estricto de esta: La de un grafo dirigido.
En un grafo dirigido, un mismo nodo puede tener varios directorios padre,
permitiendo por ejemplo que un directorio de trabajo comn sea parte del directorio personal de dos usuarios. Esto es, el mismo objeto est presente en ms
de un punto del rbol.

Figura 7: Directorio como un grafo dirigido acclico: El directorio proyecto

est tanto en el directorio /home/usr1 como en el directorio /home/usr2
Un sistema de archivos puede permitir la organizacin como un grafo dirigido, aunque es comn que la interfaz que presenta al usuario se restrinja a un
grafo dirigido acclico: Las ligas mltiples son permitidas, siempre y cuando no
generen un ciclo.
La semntica de los sistemas Unix implementa directorios como grafos dirigidos por medio de dos mecanismos:
Liga dura La entrada de un archivo en un directorio Unix es la relacin entre
7 La ruta de bsqueda refleja la organizacin del sistema de archivos en el contexto de la
instalacin especfica. Es comn que la ruta de bsqueda de un usuario estndar en Unix sea
similar a /usr/local/bin:/usr/bin:/bin:~/bin Esto significa que cualquier comando
que sea presentado es buscado, en el rden indicado, en los cuatro directorios presentados
(separados por el caracter :, la notacin ~ indica el directorio personal del usuario activo).
En Windows, es comn ver una ruta de bsqueda c:\WINDOWS\system32;c:\WINDOWS

16

la ruta del archivo y el nmero de i-nodo en el sistema de archivos.8

Si tenemos un archivo existente y creamos una liga dura a l, sta es
sencillamente otra entrada en el directorio apuntando al mismo i-nodo.
Ambas entradas, pues, son el mismo archivo No hay uno maestro y uno
dependiente.
En un sistema Unix, este mecanismo tiene slo dos restricciones:
1. Slo se pueden hacer ligas duras dentro del mismo sistema de archivos
2. No pueden hacerse ligas duras a directorios, slo a archivos9
Liga simblica Es un archivo especial, que meramente indica a dnde apunta.
El encargado de seguir este archivo a su destino (esto es, de resolver la liga
simblica) es el sistema operativo mismo; un proceso no tiene que hacer
nada especial para seguir la liga.
Una liga simblica puede apuntar a directorios, incluso creando ciclos, o
a archivos de otros sistemas de archivos.
Cuando creamos una liga simblica, la liga y el archivo son dos entidades
distintas. Si bien cualquier proceso que abra al archivo destino estar
trabajando con la misma entidad, en caso de que ste sea renombrado o
eliminado, la liga quedar rota, apuntando a una ubicacin inexistente.
Si bien estos dos tipos de liga existen tambin en los sistemas Windows10 ,
en dichos sistemas sigue siendo ms comn emplear los accesos directos. Se
denomina as a un archivo (identificado por su extensin, .lnk), principalmente
creado para poder apuntar a los archivos desde el escritorio y los menes Si
un proceso solicita al sistema abrir el acceso directo, no obtendr al archivo
destino, sino que al acceso directo mismo.
Ahora, si bien tanto las ligas duras como las ligas simblicas existen tambin en Windows, su uso es muy poco frecuente. El API de Win32 ofrece las
funciones necesarias, pero stas no estn reflejadas desde la interfaz usuario del
sistema Y son sistemas donde el usuario promedio no emplea una interfaz
programador, sino que una interfaz grfica. Las ligas, podemos concluir, no son
ms empleadas por cuestin cultural : En sus comunidades de usuarios, nunca
fueron frecuentes, por lo cual se mantienen como conceptos empleados slo por
los usuarios poderosos.
Ya con el conocimiento de las ligas, podemos presentar la figura anterior ms
apegada a la realidad: En los sistemas operativos (tanto Unix como Windows),
todo directorio tiene dos entradas especiales: Los directorios . y ..
En todos los directorios, . es una liga dura al mismo directorio, y .. es
una liga al directorio padre. Claro est, como slo puede haber una liga .., un
8 Abordaremos a detalle el significado y la estructura de un i-nodo ms adelante en esta
misma unidad
9 Formalmente, puede haberlas, pero slo el administrador puede crearlas; detallaremos el
por qu al hablar de recorrer los directorios
10 nicamente en aquellos que emplean el sistema de archivos NTFS, no en los que estn
instalados sobre alguna de las variantes de FAT

17

Figura 8: Directorio como un grafo dirigido, mostrando los enlaces ocultos . y

..
directorio que est enlazado desde dos lugares distintos del sistema de archivos
slo apunta hacia uno de ellos con su enlace ..; en este caso, el directorio
comn proyecto est dentro del directorio /home/usr2, y representamos la
liga simblica desde /home/usr1 como una lnea punteada.
Notarn que hay una excepcin: El directorio raiz. En este caso, tanto .
como .. apuntan al mismo directorio.
Y esta es la razn que mencionamos hace algunas lneas por la cual no
podemos ver a un rbol de archivos, ni en Windows ni en Unix, como a un grafo
dirigido acclico: Tanto las entradas . (al apuntar al mismo directorio donde
estn contentidas) como las entradas .. (al apuntar al directorio padre) crean
ciclos.

3.2.

Operaciones con directorios

Al igual que los archivos, los directorios tienen una semntica bsica de acceso. Los directorios resultan tambin tipos de datos abstractos con algunas
operaciones definidas Y como veremos, muchas de las operaciones que realizaremos con los directorios son anlogas a las empleadas para los archivos.11
Las operaciones bsicas a presentar son:
Abrir y cerrar Al igual que los archivos, los directorios deben ser abiertos
para trabajar con ellos, y cerrados cuando ya no se les requiera. Para
esto, en C, se emplean las funciones opendir() y closedir(). Estas
funciones trabajan asociadas a un flujo de directorio (directory stream),
que funciona de forma anloga a un descriptor de archivo.
11 De hecho, en algunos sistemas operativos, los directorios son meramente archivos de tipo
especial, que son presentados al usuario de forma distinta. Pero no adelantemos vsperas, ese
tema lo veremos ms adelante.

18

Listado de archivos Para mostrar los archivos que conforman a un directorio, el directorio se abre (tal como un archivo, pero en C, con la funcin
opendir() en vez de open()), y va leyendo (con readdir()) sus entradas una a una. Cada uno de los resultados es una estrcutura dirent
(entrada de directorio), cada una de las cuales contiene su nombre en
d_name, el identificador de su i-nodo en d_ino, y algunos datos adicionales del arcihvo en cuestin.
Para presentar al usuario la lista de archivos que conforman un directorio,
podra hacerse:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include <stdio.h>
#include <dirent.h>
#include <sys/types.h>
int main(int argc, char *argv[]) {
struct dirent *archivo;
DIR *dir;
if (argc != 2) {
printf("Indique el directorio a mostrar\n");
return 1;
}
dir = opendir(argv[1]);
while ((archivo = readdir(dir)) != 0) {
printf(" %s\t", archivo->d_name);
}
printf("\n");
closedir(dir);
}

Al igual que en al hablar de archivos, podemos rebobinar el listado del

directorio al principio del listado con rewinddir().
Buscar un elemento La mayor parte de las veces, no nos interesa tanto ver el
listado de archivos que existen, sino que abrir uno en particular Esto es,
buscar el archivo que cumpla con cierto criterio, con cierto nombre. Queda
claro que esto podemos hacerlo discriminando, de entre los resultados que
nos va arrojando readdir, y obtener la o las entradas que nos interesen.
Crear, eliminar o renombrar un elemento Si bien estas tres operaciones
se implementan por medio de una operacin de escritura en el directorio,
se implementan a travs de las funciones de manejo de archivos.
3.2.1.

Recorriendo los directorios

Es frecuente requerir aplicar una operacin a todos los archivos dentro de

cierto directorio Por ejemplo, si queremos agrupar a un directorio completo
en un archivo comprimido, o si queremos copiar todos sus contenidos a otro

19

medio. Procesar todas las entradas de un directorio, incluyendo las de sus subdirectorios, se denomina recorrer el directorio (en ingls, directory traversal ).
Si estamos trabajando en un sistema de archivos plano, la operacin de
recorrido completo puede realizarse con un programa tan simple como el que
presentamos en la seccin anterior.
Al hablar de un sistema de profundidad fija, e incluso de un directorio estructurado en rbol, la lgica se complica levemente, dado que para recorrer el
directorio tenemos que revisar, a cada entrada, si esta es a su vez un directorio
(y en caso de que as sea, entrar y procesar a cada uno de sus elementos). Hasta aqu, sin embargo, podemos recorrer el directorio sin requerir de mantener
estructuras adicionales en memoria representando el estado.
Sin embargo, cuando consideramos a los grafos dirigidos, se vuelve indispensable mantener en memoria la contabilidad de todos los nodos que ya hemos
tocado en caso contrario, al caer en un ciclo (incluso si este es creado por
mecanismos como las ligas simblicas), caeramos en un ciclo infinito.
Para esto, no bastara tomar nota de las rutas de los archivos conforme avanzamos por el grafo Cada vez que los encontremos, su ruta ser distinta (por ejemplo, veramos /home/usr/proy/archivo, seguido de /home/usr/proy/mios/archivo, a continuacin del cual seguira /home/usr/proy/mios/mios/archivo, despus de ste, seguira con
/home/usr/proy/mios/mios/mios/archivo, etc.), pero emplear un indexado basado en el nmero de i-nodo 12 identifica sin lugar a dudas a cada uno
de los archivos.
3.2.2.

Otros esquemas de organizacin

Por ms que el uso de sistemas de archivos basados en directorios jerrquicos

nos parece universal y muy ampliamente aceptado, hay cada vez ms casos de
uso que apuntan a que podemos estar por dar la bienvenida a una nueva metfora
de organizacin de archivos.
Hay distintas propuestas, y claro est, es imposible an saber cul direccin obtendr el favor del mercado O, dado que no necesariamente sigamos
teniendo un modelo apto para todos los usos, de qu segmento del mercado.

3.3.

Montaje de directorios

Para trabajar con el contenido de un sistema de archivos, el sistema operativo

tiene que montarlo: Ubicarlo en un punto del rbol de archivos visible al sistema.
Es muy comn, especialmente en los entornos derivados de Unix, que un
sistema operativo trabaje con distintos sistemas de archivos al mismo tiempo.
Esto puede obedecer a varias causas, entre las cuales tenemos:
Distintos medios fsicos Si la computadora tiene ms de una unidad de almacenamiento, el espacio dentro de cada uno de los discos se maneje como
12 Que si bien no definimos an formalmente lo que significa, sabemos que es nico por
sistema de archivos

20

un sistema de archivos indepentiente. Esto es especialmente cierto en la

presencia de unidades removibles (diskettes, CDs, unidades USB, discos
duros externos, etc.)
Diferentes usos esperados Como veremos ms adelante, distintos esquemas
de organizacin (esto es, distintos sistemas de archivos) presentan ventajas
para distintas formas de uso. Por ejemplo, tiene sentido que una base de
datos resida sobre una organizacin distinta a la de los comandos (binarios)
del sistema.
Abstracciones de sistemas no-fsicos El sistema operativo puede presentar
diversas estructuras con una estructura de sistema de archivos. El ejemplo
ms claro de esto es el sistema de archivos virtual /proc, existente en
los sistemas Unix, que permite ver diversos aspectos de los procesos en
ejecucin (y, en Linux, del sistema en general). Los archivos bajo /proc
no existen en ningn disco, pero se presentna como si fueran archivos
estndar.
Razones administrativas El administrador del sistema puede emplear sistemas de archivos distintos para aislar espacios de usuarios entre s: Por
ejemplo, para evitar que un exceso de mensajes enviados en la bitcora
(tpicamente bajo /var/log) saturen al sistema de archivos principal, o
para determinar patrones de uso mximo por grupos de usuarios.
En los sistemas tipo Unix, el mecanismo para montar los archivos es el de un
rbol con puntos de montaje. Esto es, todos los archivos y directorios del sistema
operativo estn estructurados en torno a un slo rbol. Cuando se solicita al
sistema operativo montar un sistema de archivos en determinado lugar, ste se
integra al rbol, ocultando todo lo que el directorio en cuestin previamente
tuviera.13
La manera en que esto se presenta en sistemas Windows es muy distinta.
Ah, cada uno de los sistemas de archivos detectados recibe un identificador de
volumen, y es montado automticamente en un sistema de directorio estructurado como rbol de un slo nivel representando a los dispositivos del sistema.14
Este rbol es presentado a travs de la interfaz grfica (aunque este nombre no
significa nada para el API del sistema) como Mi PC.
Entrando con el identificador de volumen, encontramos al contenido de cada
uno. De este modo, la especificacin absoluta de un archivo es una cadena como
VOL:\Dir1\Dir2\Archivo.ext El caracter : separa al volumen del rbol
del sistema de archivos, y el caracter \ separa uno de otro a los directorios.
13 Hay implementaciones que exigen que el montaje se realice exclusivamente en directorios
vacos; existen otras, como UnionFS, que buscan seguir presentando una interfaz de lectura
a los objetos que existan en el directorio previo al montaje, pero realizan las escrituras nicamente en el sistema ya montado; estas complican fuertemente algunos aspectos semnticos,
por lo cual resultan poco comunes.
14 En realidad, este rbol no slo incluye a los volmenes de almacenamiento, sino que a
los dems dispositivos del sistema, como los distintos puertos, pero los oculta de la interfaz
grfica.

21

Figura 9: rbol formado del montaje de sda1 en la raiz, sda2 como /usr,
sdb1 como /home, y el directorio virtual proc
Los identificadores de volumen estn preasignados, muchos de ellos siguiendo
a un esquema heredado desde la poca de las primeras PC: Los volmenes A y
B estn reservados para las unidades de disco flexible; C se refiere al disco duro
de arranque, y las unidades posteriores que va detectando el sistema son D, E,
F, etc.
Es posible modificar esta nomenclatura y configurar a los discos para estar en
otra ubicacin, pero muchas aplicaciones dependen ya de este comportamiento
y configuracin especficos.

Figura 10: Vista de un sistema de archivos Windows

22

3.4.

Sistemas de archivos remotos

Uno de los principales y primeros usos que se dio a la comunicacin en red fue
el de compartir archivos entre computadoras independientes. En un principio,
esto se realizaba de forma explcita, con transferencias manuales a travs de
programas dedicados a ello, como sera hoy en da el FTP.
Por otro lado, desde mediados de los 1980, es posible realizar estas transferencias de forma implcita y automtica, empleando sistemas de archivos sobre la
red (o lo que es lo mismo, sistemas de archivos remotos). Estos se nos presentan
como caso particular de la abstraccin de sistemas no-fsicos que mencionamos
en la seccin anterior: Si bien el sistema operativo no tiene acceso real a los
archivos y directorios que le solicitar el usuario, a travs de los mdulos de red,
sabe cmo obtenerlos y presentarlos como si fueran locales.
Al hablar de sistemas de archivos en red, casi siempre lo haremos siguiendo
un modelo cliente-servidor. Estos trminos no se refieren a las prestaciones relativas de una computadora, sino al rol que sta juega dentro de cada conexin
Esto es, designamos como cliente a la computadora que solicita un servicio, y
como servidor a la que lo provee; es frecuente que dos computadoras sean tanto
servidor como cliente la una de la otra en distintos servicios.
3.4.1.

Network File System (NFS)

El Sistema de Archivos en Red (Network File System, mejor conocido por

sus siglas, NFS ) fue creado por Sun Microsystems, y desde 1984 forma parte
de su sistema operativo Result una implementacin tan exitosa que a los
pocos aos formaba parte de todos los sistemas tipo Unix.
NFS est construido sobre el mecanismo RPC (Remote Procedure Call, Llamada a Procedimientos Remotos), un mecanismo de mensajes y manejo bsico
de sesin que acta como una capa superior a TCP/IP, incluyendo facilidades
de descubrimiento de recursos y abstraccin. RPC puede ser comparado con
protocolos como DCE/RPC de OSF, DCOM de Microsoft, y hoy en da, SOAP
y XML-RPC. Estos mecanismos permiten al programador delegar en un servicio el manejo de las conexiones de red, particularmente (en el caso que en
este momento nos importa) la persistencia de sesiones en caso de desconexin,
y limitar su atencin a una conexin establecida.
La motivacin de origen para la creacin de NFS fue presentar una solucin
que aprovechara el hardware existente y centralizara la administracin: Ofrecer
las facilidades para contar con redes donde hubiera un servidor de archivos, y
donde las estaciones de trabajo tuvieran nicamente una instalacin bsica,15
y el entorno de usuario completo estuviera disponible en cualquiera de las estaciones.
NFS ofrece sobre la red un sistema de archivos con la semntica Unix comple15 Incluso manejando estaciones de trabajo diskless, esto es, computadoras sin disco duro,
cuyo sistema de arranque tiene la capacidad de solicitar al servidor le enve incluso el ncleo
del sistema operativo que ejecutar

23

ta Para montar un sistema remoto, basta montarlo16 y usarlo como si fuera

local. El manejo de permisos, usuarios, e incluso las ligas duras y simblicas se
manejan exactamente como se hara localmente.
NFS es un protocolo muy ligero No implementa cifrado ni verificaciones
adicionales, pero al da de hoy, es uno de los mejores mecanismos para el envo de grandes cantidades de informacin Pero siempre en redes que sean
completamente confiables.
Ahora, NFS se presenta como uno de los componentes de una solucin completa. Dado que se espera que la informacin de usuarios y permisos sea consistente en todos los clientes; Sun ofreca tambin un esquema llamado Yellow
Pages (posteriormente renombrado a NIS, Network Information System) para
compartir la informacin de autenticacin y listas de usuarios.
La desventaja, en entornos sin NIS, es que los permisos se manejan segn
el ID numrico del usuario. Si en diferentes sistemas el mismo usuario tiene
diferentes IDs, los permisos no coincidirn. Es ms, dado que el control de
acceso principal es nicamente por direccin IP, para tener acceso irrestricto
a los archivos de otros usuarios en NFS basta con tener control pleno de una
computadora cualquiera en la red para poder asumir o usurpar la identidad de
cualquier otro usuario.
Por ltimo, para garantizar que las escrituras a archivos se llevaran a cabo
cuando eran solicitadas (en contraposicin a asumir xito y continuar), todas
las escrituras en un principio sobre NFS eran manejadas de forma sncrona, esto
es, tras grabar un archivo, el cliente no continuaba con la ejecucin hasta no
tener confirmacin por parte del servidor de que los datos estaban ya guardados
en disco.
Versiones posteriores del protocolo mejoraron sobre los puntos dbiles aqu
mencionados. Al da de hoy, casi 30 aos despus de su presentacin, NFS es
an un sistema de archivos en red muy ampliamente empleado.
3.4.2.

Common Internet File System (CIFS)

El equivalente a NFS en los entornos donde predominan los sistemas Windows es el protocolo CIFS (Common Internet File System, Sistema de Archivos
Comn para Internet). Aparece en los sistemas primarios de Microsoft alrededor
de 199017 , originalmente bajo el nombre SMB (Server Message Block, Bloque
de Mensaje del Servidor ).
Las primeras implementaciones estaban orientadas al protocolo NBF, frecuentemente conocido como NetBEUI, aunque a partir de Windows 2000 se ha
reimplementado completamente para operar sobre TCP/IP. Es a partir de este
momento que se le comienza a denominar CIFS, aunque el nombre SMB sigue
siendo ampliamente utilizado.18
16 Para
montar un sistema remoto, usaramos un comando como mount
archivos.unam.mx:/home /home
17 El desarrollo de SMB naci como LAN Manager, originalmente para OS/2
18 Es a este nombre que la implementacin de CIFS para sistemas Unix, Samba, fue llamado
de esta manera.

24

CIFS se ajusta mucho ms a la semntica de los sistemas MS-DOS y Windows, aunque dado el lapso de tiempo que ha existido, ha pasado por varios
cambios fundamentales, que al da de hoy complican su uso.
Para tener acceso a un volumen compartido por SMB se introdujo el comando NET;19 basta indicar a DOS o Windows NET USE W: \\servidor\directorio
para que el recurso compartido bajo el nombre directorio dentro del equipo conocido como servidor aparezca en el rbol Mi PC, y el usuario pueda
emplear sus contenidos como si fuera un sistema de archivos local.
Cuando fue introducido al mercado, los sistemas Microsoft no manejaban
an el concepto de usuarios, por lo que la nica medida de seguridad que implementaba SMB era el manejo de hasta dos contraseas por directorio compartido:
Con una, el usuario obtena acceso de slo lectura, y con la otra, de lectura y
escritura. Tras la aparicin de Windows NT, se agreg un esquema de identificacin por usuaro/contrasea, que posibilita el otorgamiento de permisos con
una granularidad mucho menor.20
SMB fue pensado originalmente para una red pequea, con hasta un par de
decenas de equipos. La mayor parte de los paquetes eran enviados en modo
de difusin (broadcast), por lo que era fcil llegar a la saturacin, y no exista
un esquema centralizado de resolucin de nombres, con lo que era frecuente no
encontrar a determinado equipo.
Los cambios que CIFS presenta a lo largo de los aos son muy profundos. Las
primeras implementaciones presentan fuertes problemas de confiabilidad, rendimiento y seguridad, adems de estar planteadas para su uso en un slo tipo de
sistema operativo; al da de hoy, estos puntos han todos mejorado fuertemente. En sistemas Unix, la principal implementacin, Samba, fue creada haciendo
ingeniera inversa sobre el protocolo; a lo largo de los aos, se ha convertido
en un esquema tan robusto que es hoy por hoy tomado como implementacin
refrencia.
3.4.3.

Sistemas de archivos distribudos: Andrew File System (AFS)

Los dos ejemplos de sistema de archivos en red presentados hasta ahora

comparten una visin tradicional del modelo cliente-servidor: Al ver el comando
que inicializa una conexin, e incluso a ver la informacin que guarda el ncleo
del cliente respecto a cualquiera de los archivos, resulta claro cul es el servidor
para cada uno de ellos.
Andrew File System, desarrolaldo en la Carnegie Mellon University21 y publicado en 1989, plantea presentar un verdadero sistema de archivos distribudo, en
el cual los recursos compartidos no tengan que estar en un servidor en particular,
sino que un conjunto de equipos se repartan la carga (esto es, agnosticismo a la
19 Este comando es empleado en MS-DOS, pero est tambin disponible en Windows, y al
da de hoy es una de las principales herramientas para administrar usuarios.
20 Esto significa, que puede controlarse el acceso permitido ms finamente, a nivel archivo
individual y usuario individual.
21 Como parte del Proyecto Andrew, denominado as por el nombre de los fundadores de
esta universidad: Andrew Carnegie y Andrew Mellon

25

ubicacin). AFS busca tambin una fcil escalabilidad, la capacidad de agregar

tanto espacio de almacenamiento como equipos con rol de servidor. AFS permite inclusive migrar completamente un volumen mientras est siendo empleado,
de forma transparente.
Ante la complejidad e inestabilidad adicional que nos presentan con tanta
frecuencia las redes grandes22 (y lo hacan mucho ms hace 30 aos): AFS debe
operar tan confiablemente como sea posible, incluso sin la certeza de que la red
opera correctamente.
AFS construye fuertemente sobre el modelo de tickets y credenciales de Kerberos, pero se aleja sensiblemente de la semntica de operacin de archivos que
hasta ahora hemos manejado. Muchos eventos, operaciones y estados van ligados
al momento en el tiempo en que se presentan, a travs de un modelo de consistencia dbil (weak consistency model ). Muy a grandes rasgos, esto significa
que:
Cuando se abre un archivo, ste se copia completo al cliente. Todas las
lecturas y escrituras (a diferencia de los esquemas tradicionales, en que
stas son enviadas al servidor lo antes posible y de forma sncrona) se
dirigen nicamente a la copia local.
Al cerrar el archivo, ste se copia de vuelta al servidor de origen, el cual se
compromete a notificar a los clientes si un archivo abierto fue modificado
(esto es, a hacer una llamada o callback ). Los clientes pueden entonces
intentar incorporar los cambios a su versin de trabajo, o continuar con la
copia ya obtenida Es esperable que si un segundo cliente realiza alguna
modificacin, incorpore los cambios hechos por el primero, pero esto se
deja a la implementacin del programa en cuestin.
Esto significa en pocas palabras que los cambios a un archivo abierto por
un usuario no son visibles a los dems de inmediato; slo una vez que se cierra
un archivo, los cambios hechos a ste son puestos a disposicin de las sesiones
abiertas actuales, y slo son enviados como versin actual a las sesiones abiertas
posteriormente.
Con este cambio semntico, debe quedar claro que AFS no busca ser un sistema para todo uso ni un reemplazo universal de los sistemas de archivos locales,
en contraposicin de los sistemas de archivos centralizados. AFS no plantea en
ningn momento una operacin diskless. Bajo el esquema aqu descrito, las lecturas y escrituras resultan baratas, porque se realizan exclusivamente sobre el
cach local, pero abrir y cerrar un archivo puede ser muy caro, porque debe
transferirse el archivo completo.
Hay aplicaciones que verdaderamente sufriran si tuvieran que implementarse sobre un sistema de archivos distribudo Por ejemplo, si una base de
datos se distribuyera sobre AFS, la carencia de mecanismos de bloqueo sobre
secciones del archivo, y el requisito de operar sobre archivos completos haran
impracticable compartir un archivo de uso intensivo y aleatorio.
22 El uso tpico de AFS se planteaba para organizaciones grandes, del rden de decenas de
miles de estaciones

26

4.

Plasmando la estructura en el dispositivo

Hasta ahora, hemos visto a los elementos del sistema de archivos tal como
son presentados al usuario final, sin entrar en detalles respecto a cmo organiza
toda esta informacin el sistema operativo en un dispositivo persistente Mencionamos algunas estructuras base, pero dejndolas explcitamente pendientes
de definicin. En esta seccin nos ocuparemos de detallar las principales estructuras y mecanismos empleados para que un sistema de archivos sea, ms all de
una estructura formal ideal, una entidad guardada en un dispositivo.
A lo largo de la historia del cmputo, el almacenamiento no siempre fue
hecho en discos (dispositivos giratorios de acceso aleatorio). En un principio, los
medios principales de acceso estrictamente secuencial (tarjetas perforadas, cintas
de papel, cintas magnticas), y desde hace algunos aos, estamos viendo una
migracin a almacenamiento de estado slido, a dispositivos sin partes mviles
que guardan la informacin en un tipo particular de memoria.
Los sistemas de archivo estn en general desarrollados pensando en discos,
y a lo largo de esta seccin, nos referiremos como el disco al medio de almacenamiento persistente en el cual est plasmado el sistema de archivos. Hacia el
final de la seccin abordaremos algunos de los aspectos que debemos considerar
al hablar de sistemas de archivos respaldados en medios distintos a un disco.
Mientras tanto, mantengamos una visin an bastante idealizada y abstracta: Asumamos que un disco es visto por el sistema operativo como un arreglo
muy grande de bloques de tamao fijo, cada uno de ellos directamente direccionable, y definamos los conceptos que nos permitirn representar en dicho disco
nuestro sistema operativo:
Particin Una subdivisin de un disco, por medio de la cual el administrador/usuario del sistema puede definir la forma en que se emplea el espacio
que ste ofrece. Un disco puede tener varias particiones, y cada una de
ellas puede tener un sistema de archivos independiente.
Volumen Coleccin de bloques inicializados con un sistema de archivos que
pueden presentarse al usuario como una unidad. Tpicamente un volumen
coincide con una particin (pero no siempre es el caso).
El volumen se describe ante el sistema operativo en el bloque de control de
volumen, tambin conocido como superbloque en Unix, o Tabla Maestra
de Archivos (Master File Table) en NTFS.
Directorio raiz La estructura base con la relacin entre nombres de archivo
y nmeros de i-nodo. Tpicamente slo almacena los archivos que estn
en el primer nivel jerrquico del sistema, y los directorios derivados son
nicamente referenciados desde ste.
El directorio normalmente incluye slo el nombre de cada uno de los archivos y el nmero de i-nodo que lo describe, todos los metadatos adicionales
estn en los respectivos i-nodos.

27

Metadatos Recibe este nombre toda la informacin acerca de un archivo que

no es el archivo mismo. Por ejemplo, el nombre, tamao o tipo del archivo,
su propietario, el control de acceso, sus fechas de creacin, ltimo acceso
y modificacin, ubicacin en disco, etc.
I-nodo Del ingls i-node, information node (nodo de informacin); en los sistemas tipo Windows, normalmente se le denomina bloque de control de
archivo (FCB ). Es la estructura en disco que guarda los metadatos de
cada archivo, proporcionando un vnculo entre la entrada en el directorio
y la informacin que referida.
La informacin almacenada incluye todos los metadatos relacionados con
el archivo a excepcin del nombre (mismo que radica nicamente en el
directorio): Los permisos y propietarios del archivo, sus fechas de creacin,
ltima modificacin y ltimo acceso, y la relacin de bloques que ocupa en
el disco. Veremos ms adelante los esquemas ms comunes para presentar
esta relacin de bloques.
Mapa de bits de espacio libre La funcin del bitmap es poder gestionar el
espacio libre del disco. Recordemos que el disco se presenta asignado por
bloques, tpicamente de 4096 bytes En el bitmap cada bloque se representa con un bit, con lo que aqu podemos encontrar de forma compacta
el espacio ocupado y disponible, as como el lugar adecuado para crear un
nuevo archivo.
El bitmap para un disco de 100GB puede, de esta manera, representar9
se en 23MB ( 10010
4096 ), cantidad que puede razonablemente mantener en
memoria un sistema de escritorio promedio hoy en da.
Veremos ms adelante algunas estructuras avanzadas que permiten mayor
eficiencia en este sentido.

4.1.

Diferentes sistemas de archivos

Un sistema operativo puede dar soporte a varios distintos sistemas de archivos; muchas razones pueden influir para elegir qu sistema de archivos emplearemos para nuestra informacin Algunas razones para elegir a uno u otro son
que el rendimiento de cada uno puede estaar afinado ante diferentes patrones de
carga, necesidad de emplear un dispositivo mvil para intercambiar datos con
distintos sistemas, e incluso restricciones de hardware.23
A lo largo de esta seccin iremos comentando cmo los principales conceptos que revisaremos se han implementado en distintos sistemas de archivos;
nos referiremos principalmente a una familia de sistema de archivos simple de
comprender, aunque muestra claramente su edad: La familia FAT. Ilustraremos
algunos ejemplos especficos empleando tambin otros sistemas de archivos.
23 Por ejemplo, los cargadores de arranque en algunas plataformas requieren poder leer el
volumen donde est alojada la imgen del sistema operativo Lo cual obliga a que est en
un sistema de archivos nativo a la plataforma.

28

El sistema FAT fue creado hacia fines de los 1970, y muestra claras evidencias de haber sido pensado para discos flexibles. Sin embargo, a travs de varias
extensiones que se han presentado con el paso de los aos (algunas con compatibilidad hacia atrs, otras no), sigue siendo uno de los sistemas ms empleados
al da de hoy, a pesar de que ya no es recomendado como sistema primario por
ningn sistema operativo de escritorio.
Si bien FAT tuvo su mayor difusin con los sistemas operativos de la familia
MS-DOS, es un sistema de archivos nativo para una gran cantidad de otros
sistemas, lo cual se hace obvio al revisar el soporte a atributos extendidos que
maneja.

4.2.

El volumen

Lo primero que requiere saber el sistema operativo para poder montar un

volumen es su estructura general: En primer trmino, de qu tipo de sistema de
archivos se trata, y acto seguido, la descripcin bsica del mismo: Su extensin, el
tamao de los bloques lgicos que maneja, si tiene alguna etiqueta que describa
su funcin ante el usuario, etc. Esta informacin est contenida en el bloque
de control de volumen, tambin conocido como superbloque o tabla maestra de
archivos.24
Tras leer la informacin del superbloque, el sistema operativo determina en
primer trmino si puede proceder Si no sabe cmo trabajar con el sistema de
archivos en cuestin, por ejemplo, no puede presentar informacin til alguna
al usuario.
Habamos mencionado ya que el tamao de bloques (tpicamente, 512 bytes) es establecido por el hardware. Es muy comn que, tanto por razones de
eficiencia como para alcanzar a direccionar mayor espacio, el sistema de archivos agrupe a varios bloques fsicos en un bloque lgico. Veremos ms acerca de
qu factores determinan su tamao de bloques cada sistema de archivos en la
siguiente seccin, al hablar de el directorio.
Dado que describir al volumen es la ms fundamental de las operaciones que
podamos realizar, muchos sistemas de archivos mantienen copias adicionales
del superbloque, a veces dispersas a lo largo del sistema de archivos, para poder
recuperarlo en caso de que se corrompa.
En el caso de FAT, el volumen indica no slo la generacin del sistema
de archivos que se est empleando (FAT12, FAT16 o FAT32, en los tres casos
denominados as por la cantidad de bits para referenciar a cada uno de los
bloques lgicos o clusters), sino el tamao de los clusters, que puede ir desde
los 2 y hasta los 32 Kb.
4.2.1.

Volmenes crudos

Si bien una de los principales tareas de un sistema operativo es la organizacin del espacio de almacenamiento en sistemas de archivos y su gestin para
24 Y aqu hay que aclarar: El superbloque no contiene a los archivos, ni siquiera a las
estructuras que apuntan hacia ellos, slo describe al volumen para que pueda ser montado

29

compartirse entre diversos usuarios y procesos, hay algunos casos en que un

dispositivo orientado a bloques puede ser puesto a disposicin de un proceso en
particular para que ste lo gestione directamente. Este modo de uso se denomina
el de dispositivos crudos o dispositivos en crudo (raw devices).
Podemos encontrar dos casos de uso primarios hoy en da para dispositivos
orientados a bloques no administrados a travs de la abstraccin de los sistemas
de archivos:
Espacio de intercambio Como vimos en la unidad anterior, la gestin de la
porcin de la memoria virtual que est en disco es mucho ms eficiente
cuando se hace sin cruzar por la abstraccin del sistema operativo Esto
es, cuando se hace en un volumen en crudo. Y si bien el gestor de memoria
virtual es parte innegable del sistema operativo, en un sistema microkernel
puede estar ejecutndose como proceso de usuario.
Bases de datos Las bases de datos relacionales pueden incluir volmenes muy
grandes de datos estrictamente estructurados. Algunos gestores de bases
de datos, como Oracle, MaxDB o DB2, recomiendan a sus usuarios el
uso de volmenes crudos, para optimizar los accesos a disco sin tener que
cruzar por tantas capas del sistema operativo.
La mayor parte de los gestores de bases de datos desde hace varios aos no
manejan esta modalidad, sin embargo, por la complejidad adicional que
supone para el administrador del sistema y por lo limitado de la ventaja
en rendimiento que supone hoy en da, aunque es indudablemente un tema
que se presta para discusin e investigacin.

4.3.

El directorio y los i-nodos

El directorio es la estructura que relaciona a los archivos como son presentados al usuario identificados por una ruta y un nombre con las estructuras
que los describen ante el sistema operativo Los i-nodos.
A lo largo de la historia de los sistemas de archivos, se han implementado
muy distintos esquemas de organizacin.
4.3.1.

El directorio raiz

Una vez que el sistema de archivos est montado, todas las referencias a
archivos dentro de ste deben pasar a travs del directorio. El directorio raiz
est siempre en una ubicacin bien conocida dentro del sistema de archivos
Tpicamente vamos a encontrarlo al inicio del volumen, aunque en los 1980, los
diseadores del sistema AmigaOS decidieron ubicar al directorio en el sector
central de los volmenes. Un disco flexible tena 80 pistas (tpicamente denominadas cilindros cuando hablamos de discos duros), con lo que, al ubicar al
directorio en la pista 40, el tiempo promedio de movimiento de cabezas para llegar a l se reduca a la mitad. Si todas las operaciones de abrir un archivo tienen
que pasar por el directorio, esto resultaba en una mejora muy significativa.

30

El directorio es la estructura que determina el formato que debe seguir el

nombre de cada uno de los archivos y directorios: Es comn que en un sistema
moderno, el nombre de un archivo pueda tener hasta 256 caracteres, incluyendo espacios, caracteres acentuados. Algunos sistemas de archivos son sensibles a maysculas, como es el caso de los sistemas nativos a Unix (el archivo
ejemplo.txt es distinto de Ejemplo.TXT), mientras que otros no lo son, como es el caso de NTFS y VFAT (ejemplo.txt y Ejemplo.TXT son idnticos
ante el sistema operativo).
Todas las versiones de FAT siguen para los nombres de archivos un esquema
claramente antiguo: Los nombres de archivo pueden medir hasta 8 caracteres,
con una extensin opcional de 3 caracteres ms, dando un total de 11. El sistema
no slo no es sensible a maysculas y minsculas, sino que todos los nombres
deben guardarse completamente en maysculas, y permite slo ciertos caracteres
no alfanumricos. Este sistema de archivos no implementa la separacin entre
directorio e i-nodo, que hoy es la norma, por lo que cada una de las entradas en
el directorio mide exactamente 32 bytes. Como es de esperarse en un formato
que ha vivido tanto tiempo y ha pasado por tantas generaciones como FAT,
algunos de estos campos han cambiado substancialmente sus significados:

Figura 11: Formato de la entrada del directorio bajo FAT (Mohammed, 2007)
La extensin VFAT fue agregada con el lanzamiento de Windows 95. Esta
extensin permita que, si bien el nombre real de un archivo seguira estando
limitada al formato presentado, pudieran agregarse entradas adicionales al directorio utilizando el atributo de etiqueta de volumen de maneras que un sistema
MS-DOS debiera ignorar.
Esto presenta una complicacin adicional al hablar del directorio raiz de
una unidad: Si bien los directorios derivados no tienen este lmite, al estar el
directorio raiz ubicado en una seccin fija del disco, tiene una longitud lmite
mxima: En un disco flexible (que hasta el da de hoy, por su limitada capacidad,
se formatea bajo FAT12), desde el bloque 20 y hasta el 33, esto es, 14 bloques.
Con un tamao de sector de 512 bytes, el directorio raiz mide 512 14 =
7168
entradas como mximo. Y si bien esto no nos suena
7168 bytes, esto es, 32=224
a muy limitado, ocupar cuatro entradas por archivo cuando tiene un nombre
medianamente largo va reduciendo fuertemente el panorama.
El problema no resulta tan severo como podra parecer: Para FAT32, el
directorio raiz ya no est ubicado en un espacio reservado, sino que como parte
del espacio de datos, por lo cual es extensible en caso de requerirse.
Los primeros sistemas de archivos estaban pensados para unidades de muy
31

Figura 12: Entradas representando archivo con nombre largo bajo VFAT (Peter
Clark)
baja capacidad; por mucho tiempo, las implementaciones del directorio eran
simplemente listas lineales con los archivos que estaban alojados en el volumen.
Como vimos, muchos de estos primeros sistemas no contemplaban directorios
jerrquicos, sino que presentaban un nico espacio plano de nombres; cuando estos sistemas fueron evolucionando para soportar directorios anidados, por
compatibilidad hacia atrs (y por consideraciones de rendimiento que veremos
a continuacin) siguieron almacenando nicamente al directorio raiz en esta posicin privilegiada, y manejando a todos los directorios que derivaran de ste
como si fueran archivos, repartidos por el disco.
En un sistema que implementa los directorios como listas lineales, entre ms
archivos haya, el tiempo que toma casi cualquier operacin se incrementa linealmente (dado que potencialmente tenemos que leer al directorio completo para
encontrar a un archivo). Y las listas lineales presentan un segundo problema:
Cmo reaccionar cuando se llena el espacio que tienen asignado.
Como ya mencionamos, FAT asigna un espacio fijo al directorio raiz, pero los
subdirectorios pueden crecer abritrariamente. Un subdirectorio es bsicamente
un archivo con un tipo especial de archivo Si el cuarto bit del byte 12 de
una entrada de directorio est encendido, los datos correspondientes al archivo
sern interpretados como una tabla de directorios.
Queda claro que FAT es un sistema heredado, y que exhibe muchas prcticas que ya no vemos en diseos modernos de sistemas de archivos. Vimos que
dentro de la entrada de directorio de cada archivo est prcticamente su i-nodo
completo: La informacin de permisos, atributos, fechas de creaacin Y muy
particularmente, el apuntador al cluster de inicio (bytes 26-28, mas los 20-22
para FAT32). Esto exhibe una de las grandes debilidades de FAT: La tendencia
a la fragmentacin.

32

La familia FAT obtiene su nombre de la Tabla de Asignacin de Archivos

(File Allocation Table), que aparece antes del directorio, en los primeros sectores
del disco.25 Cada byte de la FAT representa a un cluster en el rea de datos; cada
entrada en el directorio indica, en su campo cluster, cul es el primer cluster
que conforma al archivo. Ahora bien, conforme se usa un disco, y los archivos
crecen y se eliminan, y van llenando los espacios vacos que van dejando, FAT
va asignando espacio conforme encuentra nuevos clusters, sin cuidar que sea
espacio continuo. Los apuntadores al siguiente cluster se van marcando en la
tabla, cluster por cluster, y el ltimo cluster de cada archivo recibe el valor
especial (dependiendo del tipo de FAT) 0xFFF, 0xFFFF o 0xFFFFFFFF.
Ahora bien, si los directorios son sencillamente archivos que reciben un tratamiento especial, estos son tambin susceptibles a la fragmentacin. Dentro de
un sistema Windows 95 o superior (empleando VFAT), con directorios anidados
a cuatro o cinco niveles como lo establece su jerarqua estndar, el puro hecho de
recorrerlos para encontrar determinado archivo puede resultar muy penalizado
por la fragmentacin.
4.3.2.

La eliminacin de entradas del directorio

Slo unos pocos sistemas de archivos guardan sus directorios ordenados

Si bien esto facilitara las operaciones ms frecuentes que se realizan sobre de
ellos (en particular, la bsqueda Cada vez que un directorio es recorrido hasta encontrar un archivo tiene que leerse potencialmente completo), mantenerlo
ordenado ante cualquier modificacin resultara mucho ms caro, dado que tendra que reescribirse el directorio completo al crearse o eliminarse un archivo
dentro de ste, y lo que es ms importante, ms peligroso, dado que aumentara
el tiempo que los datos del directorio estn en un estado inconsistente, aumentando la probabilidad de que ante una interrupcin repentina (fallo de sistema,
corte elctrico, desconexin del dispositivo, etc.) se presentara corrupcin de la
informacin llevando a prdida de datos.
Ordenar las entradas del directorio teniendo sus contenidos ya en memoria
y, en general, diferir las modificaciones al directorio resulta mucho ms conveniente en el caso general. Esto vale tambin para la eliminacin de archivos
Presentamos, pues, la estrategia que sigue FAT . Recordemos que el diseo de
FAT fue an cuando el medio principal de almacenamiento era el disco flexible,
decenas de veces ms lento que el disco duro, y con mucha menor confiabilidad.
Cuando se le solicita a un sistema de archivos FAT eliminar un archivo, ste
no se borra del directorio, ni su informacin se libera de la tabla de asignacin de archivos, sino que se marca para ser ignorado, reemplazando el primer
caracter de su nombre por 0xE5. Ni la entrada de directorio, ni la cadena de
clusters correspondiente en las tablas de asignacin,26 son eliminadas Slo
son marcadas como disponibles. El espacio de almacenamiento que el archivo
25 Tan importante es esta tabla que se guarda por duplicado, e incluso por triplicado, dependiendo de la versin de FAT.
26 Abordaremos este tema en breve, al hablar de las tablas de asignacin de archivos

33

eliminado ocupa debe, entonces, ser sumado al espacio libre que tiene el volumen. Es apenas cuando se crea un nuevo archivo empleando esa misma entrada
que el sistema operativo marca realmente como desocupados los clusters en la
tabla de asignacin.27
Es por esto que desde los primeros das de las PC existen tantas herramientas de recuperacin (o des-borramiento) de archivos: Siempre que no haya sido
creado un archivo nuevo que ocupe la entrada de directorio en cuestin, recuperar un archivo es tan simple como volver a ponerle el primer caracter a su
nombre.
Este es un ejemplo de un mecanismo flojo (en contraposicin de los mecanismos ansiosos, como los vistos en la seccin de paginacin sobre demanda).
Eliminar un archivo toma un trabajo mnimo, mismo que es diferido al momento
de reutilizacin de la entrada de directorio.

5.

Esquemas de asignacin de espacio

Hasta ahora hemos mencionado que la entrada de directorio apunta al punto donde inicia el espacio empleado por el archivo, pero no hemos detallado en
cmo se implementa la asignacin y administracin de dicho espacio. Haremos
un breve repaso de los tres principales mecanismos, despus de lo cual detallaremos cmo es la implementacin de FAT, hablando un poco de sus virtudes y
debilidades.

5.1.

Asignacin contigua

Los primeros sistemas de archivos en disco empleaban un esquema de asignacin contigua. Para implementar un sistema de archivos de este tipo, no hara
falta el contar con una tabla de asignacin de archivos: Bastara con la informacin que vimos que forma parte del directorio de FAT La extensin del
archivo y la direccin de su primer cluster.
La principal ventaja de este mecanismo de asignacin, claro est, es la simplicidad de su implementacin. Brinda adems la mejor velocidad de transferencia
del archivo, dado que al estar cada uno de los archivos en espacio contiguo en
el disco, el movimiento de cabezas se mantiene al mnimo. Sin embargo, este
mecanismo se vuelve sumamente inconveniente en medios que soporten lectura
y escritura: Es muy sensible a la fragmentacin externa; si un archivo requiere
crecer, debe ser movido ntegramente a un bloque ms grande (lo cual toma
demasiado tiempo), y el espacio que libera un archivo en caso de reducirse su
necesidad de espacio queda atrapado entre bloques asignados; podemos tener
mucho ms espacio disponible que el que podamos asignar a un nuevo archivo.
Los esquemas de asignacin contigua se emplean hoy en da principalmente
en sistemas de archivo de slo lectura Por ejemplo, lo emplea el sistema
principal que utilizan los CD-ROMs, el ISO-9660, dado que est pensado para
27 Pero, claro, estos clusters podran mantenerse como ocupados por el nuevo archivo, ahorrando el trabajo de volver a asignarlos

34

Figura 13: Asigncin contigua de archivos: Directorio con inicio y longitud

aprovechar al mximo un espacio que, una vez grabado, slo podr abrirse en
modo de slo lectura.

5.2.

Asignacin ligada

Un enfoque completamente distinto sera el de asignacin ligada. Este esquema brinda mucho mayor flexibilidad al usuario, sacrificando la simplicidad y la
velocidad: Cada entrada en el directorio apunta a un primer grupo de sectores
(o cluster ), y ste contiene un apuntador que indica cul es el siguiente.
Para hacer esto, hay dos mecanismos: El primero, reservar un espacio al
final de cada cluster para guardar el apuntador, y el segundo, crear una tabla
independiente, que guarde nicamente los apuntadores.
En el primer caso, si manejamos clusters de 2048 bytes, y reservamos los 4
bytes (32 bits) finales de cada uno, nos encontraramos con una incomodidad al
programador: Frecuentemente, los programadores buscan alinear sus operaciones con las fronteras de las estructuras subyacentes, para optimizar los accesos
(por ejemplo, evitar que un slo registro de base de datos requiera ser ledo de
dos distintos bloques en disco). El programador tendra que disear sus estructuras para ajustarse a la poco ortodoxa cantidad de 2044 bytes.
Y ms all de esta inconveniencia, guardar los apuntadores al final de cada
cluster hace mucho ms lento el manejo de nuestros archivos: Si no tenemos
en una sola ubicacin la relacin de clusters que conforman a un archivo, para propsitos prcticos, todas las transferencias tendrn que ser secuenciales:
Si queremos llegar directamente a determinado bloque del archivo, habr que
atravesar todos los bloques previos para encontrar su ubicacin.
Particularmente por este segundo punto es mucho ms comn el empleo de
una tabla de asignacin de archivos Y precisamente as es como opera FAT
(de hecho, esta tabla es la que le da su nombre). La tabla de asignacin es un
mapa de los clusters, representando a cada uno por el espacio necesario para
guardar un apuntador.
Empleando asignacin ligada, tenemos muchas ventajas. En primer lugar,

35

Figura 14: Asigncin ligada de archivos: Directorio con apuntador slo al primer
cluster
desaparece la fragmentacin externa.28
Ahora, la asignacin ligada no slo resulta ms lenta que la contigua, sino
que presenta una mayor sobrecarga administrativa: El espacio desperdiciado
para almacenar los apuntadores tpicamente es cercano al 1 % del disponible en
el medio.
Este esquema tambin presenta fragilidad de metadatos: Si alguno de los
apuntadores se pierde o corrompe, lleva a que se pierda el archivo completo
desde ese punto y hasta su final (y abre la puerta a la corrupcin de otro
archivo, si el apuntador queda apuntando hacia un bloque empleado por ste).
Hay dos maneras de mitigar este problema: El empleado por FAT es guardar
una (o, bajo FAT12, dos) copias adicionales de la tabla de asignacin, mismas
que el sistema verificar que se mantengan consistentes. Por otro lado, podra
manejarse una estructura de lista doblemente ligada (en vez de una lista ligada
sencilla) en que cada elemento apunte tanto al siguiente como al anterior. En
ambos casos, sin embargo, la sobrecarga administrativa se duplica.

5.3.

Asignacin indexada

Por ltimo, tenemos la asignacin indexada, el mecanismo empleado por

casi todos los sistemas de archivos modernos. En este esquema, se crea una
estructura intermedia entre el directorio y los datos, nica para cada archivo: el
i-nodo (o nodo de informacin). Cada i-nodo guarda los metadatos y la lista de
bloques del archivo, reduciendo la probabilidad de que se presente la corrupcin
de apuntadores que mencionamos al hablar de la asignacin ligada.
28 El concepto que manejan los usuarios en general como fragmentacin es muy distinto, y
s se presenta bajo este esquema: Cada archivo se separa en pequeos fragmentos que pueden
terminar esparcidos por todo el disco, impactando fuertemente en el rendimiento del sistema

36

La sobrecarga administrativa bajo este esquema potencialmente es mucho

mayor: Al asignar el i-nodo, ste se crea ocupando como mnimo un cluster
completo. Para un archivo que quepa en un slo cluster, esto es un desperdicio del 100 % de espacio; para archivos ms grandes, la sobrecarga relativa
disminuye, pero se mantiene siempre superior a la de la asignacin indexada.

Figura 15: Asigncin indexada de archivos: Directorio con apuntador al i-nodo

(llevado a un i-nodo de tamao extremadamente ineficiente)
Un esquema de asignacin indexada nos da un mejor manejo de cach que la
asignacin ligada: Si bien en dicho caso es comn guardar copia de la tabla de
asignacin en memoria para mayor agilidad, con la asignacin indexada bastar
hacer cach nicamente de la informacin importante, esto es, nicamente de
los archivos que estamos empleando actualmente. Al hacer cach nicamente de
lo que es relevante al sistema en un momento dado, se da mejor uso a un recurso
ms escaso (y, por tanto, valioso): La memoria.
Ahora, qu pasa cuando la lista de clusters de un archivo no cabe en un
i-nodo? Podemos ver este ejemplo en el archivo azul del esquema ejemplo: En
este caso, cada i-nodo puede guardar nicamente tres apuntadores. Al tener un
archivo con cuatro clusters, se hace necesario extender el i-nodo con una lista
adicional. La implementacin ms comn de este esquema es que, dependiendo
del tamao del archivo, se empleen apuntadores con los niveles de indireccin
que vayan haciendo falta.
Qu tan grande sera el archivo mximo direccionable bajo este esquema
y nicamente tres indirecciones? Supongamos cantidades que podramos encontrar frecuentemente hoy en da: Clusters de 4KB y direcciones de 32 bits. Esto
significa que en un cluster vaco caben 128 apuntadores ( 4096
32 ). Supongamos
tambin que en el i-nodo los metadatos ocupan 224 bytes, dejando espacio para
100 apuntadores:
Un archivo de hasta (100 3) 4KB = 388KB puede ser representado

37

Figura 16: Estructura tpica de un i-nodo en Unix, mostrando adems el nmero

de accesos a disco necesarios para llegar a cada cluster (con slo tres cluster por
lista)
directamente en el i-nodo, y requeriremos de un slo acceso a disco para
obtener su lista de clusters
Un archivo de hasta (100 3 + 128) 4KB = 900KB puede representarse
con el bloque de indireccin sencilla, y obtener su lista de clusters nos
significa dos accesos a disco adicionales.
Con el bloque de doble indireccin, podemos referirnos a archivos mucho
ms grandes:
(100 3 + 128 + (128 128)) 4KB = 66436KB 65M B
Sin embargo, aqu ya debe llamarnos la atencin otro importante punto: Si
queremos acceder a estos 65MB, tendremos que realizar hasta 131 accesos
a disco. A partir de este punto, el sistema operativo reducir fuertemente
el tiempo de acceso si puede lograr que todos los clusters que apunten a
esta informacin estn cerca unos de otros.
38

Empleando triple indireccin, llegamos hasta:

(1003+128+(128128)+(128128128))2KB = 8455044KB 8GB
Esto es ms de lo que puede representarse en 32 bits. La cantidad de
bloques que tendramos que leer, sin embargo, para encontrar todos los
clusters nos significaran hasta 16516 accesos a disco.

5.4.

Las tablas en FAT

Volvamos al caso que estamos tomando como ejemplo, el sistema de archivos

FAT. En este sistema, cada entrada del directorio apunta al primer cluster que
ocupa ada uno de los archivos, y se emplea un esquema de asignacin ligada. El
directorio tiene tambin un campo indicando la longitud total del archivo, pero
esto no es empleado para leer la informacin, sino para poderla presentar ms
gilmente al usuario.
La estructura fundamental de este sistema de archivos es la tabla de asignacin de archivos (File Allocation Table) Tanto que de ella toma su nombre
FAT. Esta estructura ocupa los primeros sectores del disco, antes incluso del
directorio, y por su importancia, se almacena por duplicado (los discos flexibles
son mucho menos confiables que los discos duros, y el sistema de archivos fue
introducido antes de que la PC pudiera emplear un disco duro).
Cada entrada de la FAT mide lo que la longitud /correspondiente a su versin
(12, 16 o 32 bits), y puede tener uno de cuatro valores posibles:
Libre El valor 0x000, 0x0000 o 0x00000000 (dependiendo de la versin de
FAT) indica que el cluster est disponible, y puede ser asignado por el
sistema de archivos cuando haga falta.
Siguiente Cuando el valor es menor hasta 0xFF6, 0xFFF6 o 0xFFFFFFF6,
indica la ubicacin del siguiente cluster del archivo.
Daado Si el valor de una entrada es 0xFF7, 0xFFF7 o 0xFFFFFFF7, indica
que el cluster es un espacio del disco daado, y no debe ser utilizado para
almacenar datos.
Fin Los valores 0xFFF, 0xFFFF o 0xFFFFFFFF indican que se trata del ltimo
cluster de un archivo.
Una caracterstica que puede llamar la atencin de FAT es que parecera
permitir la fragmentacin de archivos por diseo: Dado que el descriptor de
cada cluster debe apuntar al siguiente, podemos asumir que el caso comn es
que los clusters no ocuparn contiguos en el disco. Claro est, la tabla puede
apuntar a varios clusters adyacentes, pero el sistema de archivos mismo no hace
nada para que as sea.
Cuando revisamos el formato del directorio de FAT omitimos un detalle
importante: Revisamos slamente el directorio raiz, y no mencionamos cmo es
que se implementan los subdirectorios. Los subdirectorios en FAT son archivos
de un tipo especial Podemos verlos como una suerte de archivos estructurados,
39

Figura 17: Ejemplo de entradas en la tabla de asignacin de archivos (Peter

Clark)
gestionados por el sistema operativo. Lo nico que distingue a un directorio de
un archivo normal es que, en la entrada que lo describe en su directorio padre,
el byte de atributos (0x0B) tiene activado el quinto bit.
Un directorio es almacenado en disto exactamente como cualquier otro archivo. Si se le asigna nicamente un cluster, y el tamao del cluster es pequeo
(2KB), podr almacenar slo 64 entradas, y cada cluster adicional le dar 64
entradas ms. Y como tal, est sujeto tambin a la fragmentacin: Conforme
se agregan entradas al directorio, ste crece. Llegado el momento, requiere clusters adicionales. Y si un directorio termina disperso por todo el disco, resultar
como cualquier otro archivo ms lento leerlo y trabajar con l. Siempre que
abramos un archivo dentro de un directorio grande, o que lo recorramos para
abrir algn archivo en algn subdirectorio suyo, tendremos que buscar todos
sus fragmentos a lo largo del disco.
Ante estos dos aspectos, no podemos perder de vista la edad que tiene FAT.
Otros sistemas de archivos ms modernos han resuelto este problema a travs
de los grupos de asignacin: Los directorios del sistema son esparcidos a lo
largo del volumen, y se intenta ubicar a los archivos cerca de los directorios
desde donde son referidos29 . Esto tiene por consecuencia que los archivos que
presentan cercana temtica quedan ubicados cerca unos de otros Y dado que
es probable que sean empleados aproximadamente al mismo tiempo, esto reduce
las distancias que recorrern las cabezas. Adems, al esparcir los archivos, se
distribuye tambin mejor el espacio libre, por lo cual el impacto de los cambios
29 Claro est, en el caso de los archivos que estn como ligas duras desde varios directorios,
pueden ubicarse slo cerca de uno de ellos

40

de tamao de un archivo en lo relativo a la fragmentacin se limita a los que

forman parte del mismo bloque de asignacin.
Los sistemas de archivos que estn estructurados siguiendo esta lgica de
grupos de asignacin no evitan la fragmentacin, pero s la mayor parte de sus
consecuencias negativas. Para mantener este esquema operando confiablemente, eso s, requieren de mantener disponibilidad de espacio Al presentarse
saturacin, esta estrategia pierde efectividad. Para evitar que esto ocurra, es
muy frecuente en los sistemas Unix que haya un cierto porcentaje (tpicamente
cercano al 5 %) del disco que est disponible nicamente para el administrador
En caso de que el sistema de archivos pase del 95 %, los usuarios no podrn
escribir ya a l, pero el administrador puede efectuar tareas de mantenimiento
para volver a un rango operacional.

6.

Fallos y recuperacin

El sistema de archivos en el cual estamos estamos basando nuestros ejemplos,

FAT, es relativamente frgil : No es difcil que se nos presente una situacin
de corrupcin de metadatos, y muy particularmente, de la estructura de las
tablas de asignacin. Los usuarios de sistemas basados en FAT en Windows
sin duda conocen a los programas CHKDSK y SCANDISK Dos programas
que implementan la misma funcionalidad base, y difieren principalmente en
su interfaz al usuario: CHKDSK existe desde los primeros aos de MS-DOS, y
est pensado para su uso interactivo en lnea de comando; SCANDISK se ejecuta
desde el entorno grfico, y presenta la particularidad de que no requiere (aunque
s recomienda fuertemente) acceso exclusivo al sistema de archivos mientras se
ejecuta. En qu basan su operacin estos programas?
A lo largo de la vida de un sistema de archivos, conforme los archivos se
van asignando y liberando, van cambiando su tamao, y conforme montamos
y des-montamos al sistema de archivos, pueden ir apareciendo inconsistencias
en su estructura. En los sistemas tipo FAT, las principales (que no las nicas)
inconsistencias son:
Archivos cruzados En ingls, cross-linked file. Recordemos que la entrada
en el directorio de un archivo incluye un apuntador al primer cluster de
una cadena. Cada cadena debe ser nica, esto es, ningn cluster debe
pertenecer a ms de un archivo. Si dos archivos incluyen al mismo cluster,
esto indica una inconsistencia, y la nica forma de resolverla es truncar a
uno de los archivos en el punto inmediato anterior a este cruce.
Cadenas perdidas o hurfanas En ingls, lost clusters. Cuando hay espacio
marcado como ocupado en la tabla de asignacin, pero no hay ninguna entrada de directorio haciendo referencia a ella, el espacio est efectivamente
bloqueado y, desde la perspectiva del usuario, inutilizado.
Cada sistema de archivos podr presentar un distinto conjunto de inconsistencias ante los fallos, dependiendo de sus estructuras bsicas y de la manera
en que cada sistema operativo las maneja.
41

Figura 18: Inconsistencias en un sistema de archivos tipo FAT

En la dcada de los 1980 comenzaron a entrar a mercado los controladores
de disco inteligentes, y en menos de diez aos dominaban ya el mercado. Estos
controladores, con buses tan dismiles como SCSI, IDE, o los ms modernos,
SAS y SATA, introdujeron muchos cambios que fueron disociando cada vez ms
al sistema operativo de la gestin fsica directa de los dispositivos; en la seccin
El medio fsico abordaremos ms a profundidad lo que esto ha significado para
el desarrollo de sistemas de archivos y algoritmos relacionados. Sin embargo,
en este tema, los controladores inteligentes resultan relevantes porque, si bien
antes el sistema operativo poda determinar con toda certeza si una operacin
se haba realizado o no, hoy en da los controladores dan un acuse de recibo
a la informacin en el momento en que la colocan en el cach incorporado del
dispositivo En caso de un fallo de corriente, esta informacin puede no haber
sido escrita por completo al disco.
Recordemos que las operaciones con los metadatos que conforman al sistema
de archivos no son atmicas. Por poner un ejemplo, crear un archivo en un
volumen FAT requiere:
1. Encontrar una lista de clusters disponibles suficiente para almacenar la
informacin que conformar al archivo
2. Encontrar el siguiente espacio disponible en el directorio
3. Crear en el espacio encontrado una entrada con el nombre que estamos
dando al archivo, apuntando al primero de los clusters
4. Marcar en la tabla de asignacin la secuencia por todos estos clusters
5. Guardar los datos del archivo en cuestin en los clusters correspondientes
Cualquier fallo que se presente despus del tercer paso (cuando hacemos la
primer modificacin) tendr como consecuencia que el archivo resulte corrupto,
42

y muy probablemente que el sistema de archivos todo presente inconsistencias

o est en un estado inconsistente.

6.1.

Datos y metadatos

Formalmente, en el ejemplo recin mencionado, el sistema de archivos estar

consistente siempre que se terminen los pasos 3 y 4 La consistencia del sistema
de archivos es independiente de la validez de los datos del archivo. Lo que busca
el sistema de archivos, ms que asegurar la integridad de los datos de uno de los
archivos, es asegurar la de los metadatos: Los datos que describen la estructura.
En caso de que un usuario desconecte una unidad a media operacin, es casi
seguro que se presentar prdida de informacin, pero el sistema de archivos
debe buscar no presentar ningn problema que ponga en riesgo operaciones
posteriores o archivos no relacionados.

6.2.

Verificacin de la integridad

Cada sistema operativo incluye programas para realizar verificacin (y, en

su caso, correccin) de la integridad de sus sistemas de archivo. En el caso de
MS-DOS y Windows, estos programas son CHKDSK y SCANDISK (diferenciados principalmente en que el primero tiene una interfaz de lnea de comando,
mientras que el segundo tiene intefaz grfica); en los sistemas Unix, el programa general se llama fsck, y tpicamente emplea a asistentes segn el tipo de
sistema a revisar fsck.vfat, fsck.ext2, etc.
Estos programas hacen un barrido del sistema de archivos, buscando evidencias de inconsistencia. Esto lo hacen, en lneas generales:
Siguiendo todas las cadenas de clusters de archivos o tablas de i-nodos,
y verificando que no haya archivos cruzados (compartiendo errneamente
bloques)
Verificando que todas las cadenas de clusters, as como todos los directorios, sean alcanzables y sigan una estructura vlida
Recalculando la correspondencia entre las estructuras encontradas y los
diferentes bitmaps y totales de espacio vaco
Estas operaciones son siempre procesos intensivos y complejos. Como requieren una revisin profunda del volmen entero, es frecuente que duren entre
decenas de minutos y horas. Adems, para poder llevar a cabo su tarea deben
ejecutarse teniendo acceso exclusivo al volumen a revisar, lo cual tpicamente
significa colocar al sistema completo en modo de mantenimiento.
Dado el elevado costo que tiene verificar el volumen entero, en la dcada
de 1990 surgieron varios esquemas orientados a evitar la necesidad de invocar
a estos programas de verificacin: Las actualizaciones suaves, los sistemas de
archivos con bitcora, y los sistemas de archivos estructurados en bitcora.

43

6.3.

Actualizaciones suaves (soft updates)

Este esquema aparentemente es el ms simple de los que presentaremos, pero

su implementacin result mucho ms compleja de lo inicialmente estimado, y en
buena medida por esta causa hoy en da no ha sido empleado ms ampliamente.
La idea bsica detrs de este esquema es estructurar el sistema de archivos de
una forma ms simple y organizar las escrituras al mismo de modo que el estado
resultante no pueda ser inconsistente, ni siquiera en caso de fallo, y de exigir
que todas las operaciones de actualizacin de metadatos se realicen de forma
sncrona.30
Ante la imposibilidad de tener un sistema siempre consistente, esta exigencia
se relaj para permitir inconsistencias no destructivas: Pueden presentarse cadenas perdidas, dado que esto no pone en riesgo a ningn archivo, slo disminuye
el espacio total disponible.
Esto, aunado a una reestructuracin del programa de verificacin (fsck) como una tarea ejecutable en el fondo y en una tarea de recolector de basura, que
no requiere intervencin humana (dado que no pueden presentarse inconsistencias destructivas), permite que un sistema de archivos que no fue limpiamente
desmontado pueda ser montado y utilizado de inmediato, sin peligro de prdida
de informacin o de corrupcin.
Al requerir que todas las operaciones sean sncronas, parecera que el rendimiento global del sistema de archivos tendra que verse afectado, pero por
ciertos patrones de acceso muy frecuentes, resulta incluso beneficioso. Al mantenerse un ordenamiento lgico de las dependencias de todas las operaciones
que estn pendientes, el sistema operativo puede combinar a muchas de estas y
reducir de forma global las escrituras a disco Por ejemplo, si varios archivos
son creados en el mismo directorio de forma consecutiva, cada uno de ellos a
travs de una llamada open() independiente, el sistema operativo combinar
a todos estos accesos en uno slo, reduciendo el nmero de llamadas. Al crear
un archivo de uso temporal, un patrn frecuente en sistemas Unix es solicitar al
sistema la creacin de un archivo, abrir el archivo recin creado, y ya teniendo
al descriptor de archivo, eliminarlo En este caso, con estas tres operaciones
seguidas, soft updates podra ahorrarse por completo la escritura a disco.
Esta estrategia fue implementada hacia 2002 en el sistema operativo
FreeBSD, y fue adoptada por los principales sistemas de la familia *BSD, aunque NetBSD lo retir en 2012, prefiriendo el empleo de sistemas con bitcora
Muy probablemente, la lgica destrs de esta decisin sea la cantidad de
sistemas que emplean esta segunda estrategia que veremos a continuacin, y lo
complejo de mantener dentro del ncleo dos estrategias tan distintas.
Adems de esto, esta estrategia tambin se vio impactada por los controladores inteligentes: Si un disco est sometido a carga intensa, no hay garanta
para el sistema operativo del rden que seguirn en verdad sus solicitudes, que
se forman en el cach propio del disco. Dado que las actualizaciones suaves dependen tan profundamente de confiar en el ordenamiento, esto introduce an
30 Esto es, no se le reporta xito en alguna operacin de archivos al usuario sino hasta que
sta es completada y grabada a disco

44

ms complejidad en el proceso.

6.4.

Sistemas de archivo con bitcora (journaling file systems)

Este esquema tiene su origen en el mbito de las bases de datos distribudas.

Consiste en separar un rea del volumen y dedicarla a llevar una bitcora con
todas las transacciones de metadatos.31 Una transaccin es un conjunto de
operaciones que deben aparecer como atmicas.
La bitcora es generalmente implementada como una lista ligada circular,
con un apuntador que indica cul fue la ltima operacin realizada exitosamente. Peridicamente, o cuando la carga de transferencia de datos disminuye, el
sistema verifica qu operaciones quedan pendientes, y avanza sobre la bitcora,
marcando cada una de las transacciones conforme las realiza.
En caso de tener que recuperarse de una condicin de fallo, el sistema operativo slo tiene que leer la bitcora, encontrar cul fue la ltima operacin
comprometida, y aplicar las restantes.
Una restriccin de este esquema es que las transacciones guardadas en la
bitcora deben ser idempotentes Esto es, si una de ellas es efectuada dos veces,
el efecto debe ser exactamente el mismo que si hubiera sido efectuada una sla
vez. Por poner un ejemplo, no sera vlido que una transaccin indicara Agregar
al directorio x un archivo llamado y, dado que si la falla se produce despus de
procesar esta transaccin pero antes de avanzar al apuntador de la bitcora, el
directorio x quedara con dos archivos y Una situacin inconsistente. En todo
caso, tendramos que indicar registrar al archivo y en la posicin z del directorio
x ; de esta manera, incluso si el archivo ya haba sido registrado, puede volverse
a registrar sin peligro.
Este esquema es el ms implementado hoy en da, y est presente en casi
todos los sistemas de archivos modernos. Si bien con un sistema con bitcora no
hace falta verificar el sistema de archivos completo tras una detencin abrupta,
esta no nos exime de que, de tiempo en tiempo, el sistema de archivos sea
verificado: Es altamente recomendado hacer una verificacin peridica en caso
de presentarse alguna corrupcin, sea por algn bug en la implementacin, fallos
en el medio fsico, o factores similarmente poco frecuentes.

6.5.

Sistemas de archivos estructurados en bitcora (logstructured file systems)

Si llevamos el concepto del sistema de archivos con bitcora a su lmite, y

designamos a la totalidad del espacio en el volumen como la bitcora, hablamos
de un sistema de archivos estructurado en bitcora. Obviamente, este tipo de
sistemas de archivos presenta una organizacin completa radicalmente diferente
de los sistemas de archivo tradicionales.
31 Existen implementaciones que registran tambin los datos en la bitcora, pero tanto por el
tamao que sta requiere como por el impacto en velocidad que significa, son poco utilizadas.

45

Figura 19: Sistema de archivos con bitcora

Las ideas bsicas detrs de la primer implementacin de un sistema de archivos de esta naturaleza (Ousterhut y Rosenblum, 1992) apuntan al empleo
agresivo de cach de gran capacidad, y con un fuerte mecanismo de recoleccin
de basura, reacomodando la informacin que est ms cerca de la cola de la
bitcora (y liberando toda aquella que resulte redundante).
Este tipo de sistemas de archivos facilita las escrituras, hacindolas siempre
secuenciales, y buscan a travs del empleo del cach ya mencionado evitar
que las cabezas tengan que desplazarse con demasiada frecuencia para recuperar
fragmentos de archivos.
Una consecuencia directa de esto es que los sistemas de archivos estructurados en bitcora fueron los primeros en ofrecer fotografas (snapshots) del sistema
de archivos: Es posible apuntar a un momento en el tiempo, y con el sistema de
archivos an en operacin montar una copia de slo lectura con la informacin
del sistema de archivos completa (incluyendo los datos de los archivos).
Los sistemas de archivo estructurados en bitcora, sin embargo, no estn
optimizados para cualquier carga de trabajo. Por ejemplo, una base de datos relacional, en que cada uno de los registros es tpicamente actualizados de forma
independiente de los dems, y ocupan apenas fracciones de un bloque, resultara tremendamente ineficiente. La implementacin referencia de Ousterhut y
Rosenblum fue parte de los sistemas *BSD, pero dada su tendencia a la extrema
fragmentacin, fue eliminado de ellos.
Este tipo de sistemas de archivo ofrece caractersticas muy interesantes, aunque es un campo que an requiere de mucha investigacin e implementaciones
ejemplo. Muchas de las implementaciones en sistemas libres han llegado a niveles de funcionalidad aceptables, pero por diversas causas han ido perdiendo el
inters o el empuje de sus desarrolladores, y su ritmo de desarrollo ha decrecido.
Sin embargo, varios conceptos muy importantes han nacido bajo este tipo de
sistemas de archivos, algunos de los cuales (como el de las fotografas) se han

46

ido aplicando a sistemas de archivo estndar.

Por otro lado, dado el fuerte crecimiento que estn registrando los medios
de almacenamiento de estado slido (abordaremos en breve algunas de sus caractersticas), y dado que estos sistemas aprovechan mejor varias de sus caractersticas, es probable que el inters en estos sistemas de archivos resurja.

7.

El medio fsico

Hasta este punto, y siguiendo las prcticas a que la realidad de los ltimos
40 aos nos han acostumbrado, hemos empleado el trmino genrico de disco
para nuestra discusin.
En esta seccin, abordaremos en primer trmino las caractersticas principales del medio an prevalente, los discos duros magnticos rotativos, y presentaremos una introduccin a las diferencias que encontraremos en otros medios,
como los discos pticos y los de estado slido, y las implicaciones que stos
tienen sobre lo que venimos discutiendo a lo largo de la unidad.

7.1.

Discos magnticos rotativos

El principal medio de almacenamiento que hemos empleado en los ltimos 40

aos es el disco magntico. Hay dos tipos diferentes de disco, aunque la lgica
de su funcionamiento es la misma: Los discos duros y los discos flexibles (o
floppies).
La principal diferencia entre estos es que los primeros son tpicamente almacenamiento interno en los equipos de cmputo, y los segundos estn pensados
para ser almacenamiento transportable. Los discos duros tienen mucha mayor
capacidad y son mucho ms rpidos, pero a cambio de ello, mucho ms sensibles
a la contaminacin por partculas de polvo y a daos mecnicos.
Un disco flexible es una hoja de material plstico, muy similar al empleado
en las cintas magnticas, resguardado por un estuche plstico. Al insertarse el
disco en la unidad lectora, esta lo hace girar sujetndolo por el centro, y las
cabezas lectoras32 se deslizan por una ventana que tiene el estuche. La mayor
parte de los discos flexibles presentaban velocidades de rotacin de entre 300 y
400 revoluciones por minuto.
A lo largo de ms de 20 aos se presentaron muy diferentes formatos fsicos
siguiendo esta misma lgica, designndose principalmente por su tamao (en
pulgadas). La capacidad de los discos, claro est, fue creciendo con el paso de
los aos Esto explica la aparente contradiccin de que los discos ms chicos
fsicamente tenan ms capacidad que los ms grandes.
El nombre de disco duro o disco flexible se debe al medio empleado para el
almacenamiento de la informacin: Mientras que los discos flexibles emplean,
como mencionamos, una hoja plstica flexible, los discos duros son metlicos.
Los discos estn permanentemente montados sobre un eje, lo que permite que
32 en un principio una sola; posteriormente aparecieron las unidades de doble cara, con dos
cabezas lectoras

47

Cuadro 1: Principales formatos de disco flexible que se popularizaron en el mercado

Fecha de introduccin
Capacidad
Velocidad (kbit/s)
Pistas por pulgada

8 pulgadas
1971
150KB-1.2MB
33
48

5.25 pulgadas
1976
110KB-1.2MB
125-500
48-96

3.5 pulgadas
1982
264KB-2.88MB
250-1000
135

tengan una velocidad de giro entre 20 y 50 veces ms rpida que los discos
flexibles Entre 4,200 y 15,000 revoluciones por minuto (RPM), esto es, con
una demora rotacional de entre 2 y 7.14 milisegundos..
Adems, a excepcin de algunos modelos tempranos, los discos duros constituyen un paquete cerrado y sellado que incluye las cabezas de lectura y escritura,
y toda la electrnica de control. Esto permite que los discos duros tengan densidades de almacenamiento y velocidades de transmisin muy superiores a la
de los discos flexibles: Los primeros discos duros que se comercializaron para
computadoras personales eran de 10MB (aproximadamente 70 discos flexibles
de su poca), y actualmente hay ya discos de 4TB. La velocidad mxima de
transferencia sostenida hoy en da es superior a los 100MB por segundo, 100
veces ms rpido que la ltima generacin de discos flexibles.
Para medir la eficiencia de un disco duro, el otro dato importante es el tiempo
que toma la cabeza en moverse a travs de la superficie del disco. Hoy en da,
las velocidades ms comunes son de 20ms para un recorrido completo (desde
el primer hasta el ltimo sector), y entre 0.2ms y 0.8ms para ir de un cilindro
al inmediato siguiente. Como punto de comparacin, el recorrido completo en
una unidad de disco flexible toma aproximadamente 100ms, y el tiempo de un
cilindro al siguiente va entre 3 y 8ms.
7.1.1.

Notacin C-H-S

Independientemente de la tecnologa, la manera en que el sistema operativo

hace referencia a la ubicacin de un bloque de informacin en el disco es conocido como la notacin C-H-S Indicando el cilindro, cabeza y sector (Cylinder,
Head, Sector ) de la informacin. Esto permite mapear el espacio de almacenamiento de un disco a un espacio tridimensional, con cual resulta trivial ubicar
a alguna estructura en una regin contigua.
La cabeza indica a cul de las superficies del disco nos referimos; en un disco
flexible, tenemos slo dos cabezas, pero en un disco duro es comn tener varios
platos paralelos. Todas las cabezas van fijas a un mismo motor, y no pueden
moverse de forma independiente.
El cilindro indica la distancia del centro a la orilla del disco.
Un sector es un segmento de arco de uno de los cilindros.
Es frecuente ver referencias a una pista (track ), esto es, a un cilindro en una

48

Figura 20: Coordenadas de un disco duro, presentando cada uno de sus sectores
en C-H-S (Silberschatz, p.458)
de las superficies del disco Un archivo almacenado secuencialmente ocupa
sectores adyacentes a lo largo de una misma pista.
7.1.2.

Algoritmos de planificacin de acceso a disco

Como hemos visto, las transferencias a disco son uno de los procesos ms
lentos de los que gestiona el sistema operativo. Cuando ste tiene varias solicitudes de transferencia pendientes, resulta importante encontrar un mecanismo
ptimo para realizar la transferencia, minimizando el tiempo de demora. Presentaremos a grandes rasgos tres de los algoritmos de planificacin de acceso
a disco Pero abordaremos tambin el por qu estos hoy en da casi no son
empleados.
Como con los dems escenarios que hemos abordado analizando algoritmos,
para analizar su rendimiento tenemos que presentar una cadena de referencia.
En este caso, trabajaremos con un disco hipottico de 200 cilindros, la cadena
de solicitudes 98, 183, 37, 122, 14, 124, 65, 67, y teniendo la cabeza al inicio
de la operacin en el cilindro 53.
Veamos, pues, de forma grfica la respuesta que presentaran los distintos
algoritmos ante la cadena de referencia dada, y procedamos a comparar a los
algoritmos en cuestin.
FIFO Al igual que cuando hablamos de algoritmos de asignacin de procesador
y de reemplazo de pginas, el primero y ms sencillo de implementar es
el FIFO Primero en llegar, primero en servirse. Este algoritmo puede
verse como muy justo, aunque sea muy poco eficiente: El movimiento total
49

Figura 21: Movimientos de las cabezas bajo los diferentes algoritmos planificadores de acceso a disco, indicando la distancia total recorrida por la cabeza
bajo cada uno, iniciando con la cabeza en la posicin 53. Para SCAN, LOOK y
C-SCAN, asumimos que iniciamos con la cabeza en direccin decreciente.
de cabezas para el caso planteado es de 640 cilindros, equivalente a poco
ms que recorrer de extremo a extremo el disco completo tres veces. Esto
es, despreciando la demora rotacional y el tiempo que le toma al brazo
detenerse por completo antes de volver a moverse, esta lectura tomara un
mnimo de 60ms, siendo el recorrido completo del disco 20ms.
Podemos encontrar al causante de buena parte de esta demora en la quinta
posicin de la cadena de referencia: Entre solicitudes para el cilindro 122
y 124, tenemos una solicitud al 14, que significa un desplazamiento de
(122 14) + (124 14) = 218 sectores.
SSTF Ahora bien, si el factor que impone la principal demora es el movimiento
de la cabeza, el segundo algoritmo busca reducir al mnimo el movimiento
de la cabeza: SSTF (Shortest Seek Time First, Tiempo de bsqueda ms
corto a continuacin) es el equivalente en este mbito del Shortest Job
First que vimos en planificacin de procesos con la ventaja de que no
estamos prediciendo comportamiento futuro, sino que tenemos ya la lista
de solicitudes pendientes. Empleando SSTF, el tiempo de desplazamiento
para este caso se reduce a tan slo 236 cilindros muy cerca del mnimo
absoluto posible.

50

Una desventaja de SSTF es que puede llevar a la inanicin: Si hay una

gran densidad de solicitudes para cilindros en determinada zona del disco,
una solicitud para un cilindro alejado puede quedar a la espera indefinidamente. Ejemplifiquemo esto con una serie de solicitudes distinta a la que
estamos tomando como referencia: Si el sistema tuviera la cadena de solicitudes 15, 175, 13, 20, 14, 32, 40, 5, 6, 7, SSTF penalizara a la segunda
solicitud (175) hasta terminar con los cilindros bajos.
Familia de algoritmos de elevador (SCAN, LOOK, C-SCAN) Hablamos
en este tercer lugar no de un algoritmo, sino que de una familia, dado que
parten de la misma idea, pero con modificaciones menores llevan a que el
patrn de atencin resultante sea muy distinto.
El planteamiento base para el arlgoritmo bsico de elevador (SCAN) busca
evitar la inanicin, minimizando al mismo tiempo el movimiento de las
cabezas. Su lgica marca que la cabeza debe recorrer el disco de extremo
a extremo, como si fuera un elevador en un edificio alto, atendiendo a todas
las solicitudes que haya pendientes en su camino. Si bien los recorridos para
ciertos patrones pueden resultar en mayores desplazamientos a los que
dara SSTF, la garanta de que ningn proceso esperar indefinidamente
lo hace muy atractivo.
Atender la cadena de referencia con la que estamos trabajando bajo SCAN,
asumiendo un estado inicial descendente (esto es, la cabeza est en el
cilindro 53 y va bajando) da un recorrido total de 236 cilindros; empleando
LOOK, se reduce a 208 cilindros, y evita el movimiento innecesario hasta
el lmite del disco.
Una primer (y casi obvia) modificacin a este algoritmo sera, cada vez que
la cabeza se detenga para satisfacer una solicitud, verificar si hay alguna
otra solicitud pendiente en la direccin actual, y de no ser as, emprender
el camino de regreso sin llegar a la orilla del disco. Esta modificacin es
frecuentemente descrita como LOOK.
Sin embargo, el patrn de atencin a solicitudes de SCAN y LOOK dejan
qu desear: Al llegar a un extremo del recorrido, es bastante probable que
no haya ninguna solicitud pendiente en la primer mitad del recorrido de
vuelta (dado que acaban de ser atendidas). El tiempo que demora atender
a una solictud se compone de la suma del desplazamiento de la cabeza
y la demora rotacional (que depende de cul sector del cilindro nos fue
solicitado). Para mantener una tasa de transferencia ms predecible, el
algoritmo C-SCAN (SCAN Circular) realiza las operaciones en el disco
nicamente en un sentido Si el algoritmo lee en rden descendente, al
llegar a la solicitud del cilindro ms bajo, brincar de vuelta hasta el ms
alto para volver a iniciar desde ah. Esto tiene como resultado, claro, que
el recorrido total aumente (aumentando hasta los 326 para nuestra cadena
de referencia.

51

7.1.3.

Limitaciones de los algoritmos presentados

Ahora, mencionamos que estos algoritmos hoy en da ya casi no se usan.

Hay varias razones para ello. En primer trmino, todos ellos estn orientados
a reducir el traslado de la cabeza, pero ignoran la demora rotacional. Como
1
vimos, en los discos duros actuales, la demora rotacional va entre 10
y 31 del
tiempo total de recorrido de la cabeza. Y si bien el sistema podra considerar
esta demora como un factor adicional al planificar el siguiente movimiento de
forma que se redujera el tiempo de espera, los algoritmos descritos obviamente
requieren ser replanteados por completo.
Por otro lado, el sistema operativo muchas veces requiere dar distintas prioridades a los diferentes tipos de solicitud. Por ejemplo, sera esperable dar preferencia a los accesos a memoria virtual por encima de las solicitudes de abrir
un nuevo archivo. Estos algoritmos tampoco permiten expresar esta necesidad.
Pero el tercer punto es mucho ms importante an: Del mismo modo en
que los procesadores se van haciendo ms rpidos y que la memoria es cada
vez de mayor capacidad, los controladores de discos tambin son cada vez ms
inteligentes, y esconden cada vez ms informacin del sistema operativo, por lo
cual ste cada vez ms carece de la informacin necesaria acerca del acomodo
real de la informacin como para planificar correctamente sus accesos.
Uno de los cambios ms importantes en este sentido fue la transicin del
empleo de la notacin C-H-S al esquema de direccionamiento lgico de bloques
(Logical Block Addressing, LBA) a principios de los 1990. Hasta ese momento, el
sistema operativo tena informacin de la ubicacin fsica de todos los bloques
en el disco.
Una de las desventajas, sin embargo, de este esquema es que el mismo BIOS
tena que conocer la geometra de los discos Y el BIOS presentaba lmites
duros en este sentido: Principalmente, no le era posible referenciar ms all
de 64 cilindros. Al aparecer la interfaz de discos IDE (Electrnica integrada al
dispositivo) e ir reemplazando a la ST-506, se introdujo LBA, que en un primer
trmino de la direccin C-H-S a una direccin lineal, presentando el disco al
sistema operativo ya no como un espacio tridimensional, sino que como un gran
arreglo de bloques. En este primer momento, la equivalencia de una direccin
C-H-S a una LBA era:
LBA = ((C HP C) + H) SP T + S 1
Donde HP C es el nmero de cabezas por cilindro, SP T es el nmero de
sectores por pista.
LBA signific mucho ms que una nueva notacin Marc el inicio de la
transferencia de inteligencia y control del CPU al controlador de disco. Podemos
ver el impacto de esto directamente en dos factores:
Sectores variables por cilindro En casi todos los discos previos a LBA33 ,
33 Como muy notorias excepciones tenemos a las unidades de disco Commodore 1541 y
Macintosh Superdrive, que empleaban velocidad variable por cilindro para aprovechar mejor
el medio magntico; en ambos casos, sin embargo, terminaron desapareciendo por cuestiones
de costos y de complejidad al sistema

52

el nmero de sectores por pista se mantena constante, se tratara de las

pistas ms internas o ms externas. Esto significa que, a igual calidad de la
cobertura magntica del medio, los sectores ubicados en la parte exterior
del disco desperdiciaban mucho espacio (ya que el rea por bit era mucho
mayor).

Figura 22: Disco formateado bajo densidad de bits por zona, con ms sectores
por pista en las pistas exteriores. (Imagen: Wikipedia)
Bajo LBA, los discos duros comenzaron a emplear un esquema de densidad de bits por zona (zone bit recording), con la que en los cilindros ms
externos se aumenta.
Reubicacin de sectores Conforme avanza el uso de un disco, es posible que
algunos sectores vayan resultando difciles de leer por daos microscpicos
a la superficie. El controlador es capaz de detectar estos problemas, y de
hecho, casi siempre puede rescatar la informacin de dichos sectores de
forma imperceptible al usuario.
Los discos duros ST-506 tpicamente venan acompaados por una lista de
defectos, una lista de coordenadas C-H-S que desde su fabricacin haban
presentado errores. El usuario deba ingresar estos defectos al formatear
el disco a bajo nivel.
Hoy en da, el controlador del disco detecta estos fallos y se los brinca,
presentando un mapa LBA lineal y completo. Los discos duros tpicamente
vienen con cierto nmero de sectores de reserva para que, conforme se
van detectando potenciales daos, estos puedan reemplazarse de forma
transparente.
Sumemos a esto que los controladores de disco tienen ya incluso cach para
las operaciones de lectura y escritura El controlador del disco es hoy en
da capaz de implementar estos mismos algoritmos de forma completamente
autnoma del sistema operativo.

53

Resulta claro que, dados estos cambios en la manera en que hacemos referencia a los bloques del disco, el sistema operativo no cuenta ya con la informacin
necesaria para emplear los algoritmos de planificacin de acceso a disco.

7.2.

Almacenamiento en estado slido

Desde hace cerca de una dcada va creciendo consistentemente el uso de medios de almacenamiento de estado slido Esto es, medios sin partes mviles.
Las caractersticas de estos medios de almacenamiento son muy distintas de las
de los discos. Si bien las estructuras que emplean hoy en da prcticamente todos
los sistemas de archivos en uso mayoritario estn pensadas y estructuradas siguiendo la lgica de los medios magnticos rotativos, la necesidad de emplear las
estructuras adecuadas es clara. Este es indudablemente un rea bajo intensa investigacin y desarrollo, y que seguramente nos ofrecer importantes novedades
en los prximos aos.
Lo primero que llama la atencin de estos medios de almacenamiento es que,
a pesar de ser fundamentalmente distintos a los discos magnticos, se presentan
ante el sistema operativo como si fueran lo mismo: En lo que podra entenderse
como un esfuerzo para ser utilizados pronto y sin cambios, se conectan a travs de
la misma interfaz y empleando la misma semntica que un disco rotativo. Esto no
slo evita que se aprovechen sus caractersticas nicas, adoptando restricciones
y criterios de diseo que ahora resultan indudablemente artificiales, sino que
incluso se exponen a mayor stress por no emplearse de la forma que les resultara
natural. Antes de ver por qu, veamos un poco los tipos de discos de estado solido
que hay; esto nos dar pie a entender las caractersticas a las que en este prrafo
hacemos referencia.
Al hablar de la tecnologa sobre la cual se implementa este tipo de almacenamiento, encontraremos dos medios principales:
NVRAM Unidades RAM No Voltil. Almacenan la informacin en memoria
RAM estndar, con un respaldo de batera para mantener la informacin
cuando se desconecta la corriente externa. Las primeras unidades de estado
slido eran de este estilo; hoy en da son poco comunes en el mercado, pero
siguen existiendo.
Su principal ventaja es la velocidad y durabilidad: El tiempo de acceso
o escritura de datos es el mismo que el que esperaramos de la memoria
principal del sistema, y al no haber demoras mecnicas, este tiempo es el
mismo independientemente de la direccin que se solicite.
Su principal desventaja es el precio: En lneas generales, la memoria RAM
es, por volumen de almacenamiento, cientos de veces ms cara que el medio
magntico. Y si bien el medio no se degrada con el uso, la batera s, lo
que podra poner en peligro a la supervivencia de la informacin.
Estas unidades tpicamente se instalan internamente como una tarjeta de
expansin.
./img/estado_solido_ddr_drivex1.jpg
54

Memoria flash Derivada de los EEPROM (Electrically Erasable Programmable Read-Only Memory, Memoria de Slo Lectura Programable y Borrable
Elctricamente). Los EEPROM tienen la caracterstica de que, adems de
lectura y escritura, hay un tercer tipo de operacin que deben implementar: El borrado. Un EEPROM ya utilizado debe borrarse antes de volverse
a escribir a l. La principal caracterstica que distingue a las memorias
flash de los EEPROMs tradicionales es que el espacio de almacenamiento
est dividido en pginas o bloques, y el controlador puede leer, borrar o
escribir a cada uno de ellos por separado.
El uso de dispositivos flash para almacenamiento de informacin inici
hacia 1995 como respuesta a las necesidades de las industrias aeroespacial
y militar, dada la frecuencia de los daos a la informacin que presentaban
los medios magnticos por la vibracin. Hoy en da hay dispositivos flash
de muy bajo costo y capacidad, aunque presentan una gran variabilidad
tanto en su tiempo de acceso como en su durabilidad. En este sentido,
podemos hablar de dos tipos principales de dispositivos flash:
Almacenamiento primario (SSD) Las llamadas formalmente unidad
de estado slido (Solid State Drive)34 son unidades Flash de alta
velocidad y capacidad, y tpicamente presentan una interfaz similar
a la que tienen los discos duros (hoy en da, la ms comn es SATA).
./img/estado_solido_sata.jpg
Su velocidad de lectura es muy superior y su velocidad de escritura
(incluyendo el borrado) es comparable a la de los discos magnticos.
Su precio por el mismo volumen de almacenamento es entre 5 y 10
veces el de los discos magnticos.
Podemos encontrar este tipo de unidades tanto como unidades independientes en servidores, equipos de alto desempeo e incluso algunas
subporttiles (netbooks) o como un componente de la tarjeta madre
en dispositivos mviles como telfonos y tabletas.
Transporte de archivos Esta tecnologa tambin est presente en las
diversas unidades extrables o mviles, como las unidades USB, SD,
Memory Stick, Compact Flash, etc. La principal diferencia entre estas son los diferentes conectores que emplean; todas estas tecnologas
presentan dispositivos que varan fuertemente en capacidad, velocidad y durabilidad.
./img/estado_solido_usb.jpg
Independientemente del tipo, las unidades de estado slido presentan ventajas ante los discos rotativos, como un muy bajo consumo elctrico, operacin
completamente silenciosa, y resistencia a la vibracin o a los golpes. Adems, el
medio es verdaderamente de acceso aleatorio: Al no ser ya un disco, desaparecen
tanto la demora de movimiento de cabezas como la rotacional.
34 Un error muy comn es confundir la D con Disk, que denotara que llevan un disco, un
medio rotativo

55

7.2.1.

Desgaste del medio

La memoria Flash presenta patrons de desgaste muy distintos de los que podemos ver en otros medios. La memoria Flash tiene capacidad de aguantar un
cierto nmero de operaciones de borrado por pgina.35 Las estructuras tradicionales de sistemas de archivos basados en disco concentran una gran cantidad de
modificaciones en ciertas regiones clave: Las tablas de asignacin y directorios
registran muchos ms cambios que la regin de datos.
Casi todos los controladores de discos Flash cuentan con mecanismos de nivelamiento de escrituras (write leveling). Este mecanismo busca reducir el desgaste focalizado modificando el mapeo de los sectores que ve el sistema operativo
respecto a los que son grabados en verdad en el medio: En vez de actualizar un
bloque (por ejemplo, un directorio) en su lugar, el controlador le asigna un nuevo
bloque de forma transparente, y marca el bloque original como libre.
Los mecanismos ms simples de nivelamiento de escrituras lo hacen nicamente intercambiando los bloques libres con los recin reescritos; mecanismos
ms avanzados buscan nivelar el nivel de reescritura en toda la unidad reubicando tambin a los bloques que tpicamente slo se leen.
7.2.2.

Emulacin de discos

Hoy en da, la casi totalidad de medios de estado sldo se presentan ante el

sistema con una interfaz que emula la de los discos, la FTL (Flash Translation
Layer, Capa de Traduccin de Flash). La ventaja de esta emulacin es que no
hizo falta desarrollar controladores adicionales para comenzar a emplear estos
medios. La desventaja, sin embargo, es que al ocultarse el funcionamiento real
de las unidades de estado slido, el sistema operativo no puede aprovechar las
ventajas estructurales Y ms importante an, no puede evitar las debilidades
inherentes al medio.
Uno de los ejemplos ms claros de esta falta de control real del medio la
ilustra el artculo de Valerie Aurora (2009), que menciona que tanto la poca
informacin pblicamente disponible acerca del funcionamiento de los controladores como los patrones de velocidad y desgaste de los mismos apuntan a
que la estructura subyacente de casi todos los medios de estado slido es la de
un sistema de archivos estructurado en bitcora. Aurora indica que hay varias
operaciones que no pueden ser traducidas eficientemente a travs de esta capa
de emulacin, y que seguramente permitiran un mucho mejor aprovechamiento
del medio. Como mencionamos en la seccin que describe los sistemas de archivo estructurados en bitcora, si bien varios de estos sistemas de archivos han
presentado implementaciones completamente utilizables, la falta de inters ha
llevado a que muchos de estos proyectos sean abandonados.
En su artculo de 2012, Neil Brown apunta a que Linux tiene una interfaz
apta para hablar directamente con dispositivos de estado slido, llamada mtd
memory technology devices, dispositivos de tecnologa de memoria.
35 Dependiendo

de la calidad, va entre las 3,000 y 100,000

56

Como lo mencionamos al inicio de esta seccin, si bien los discos duros se

han empleado por ya 50 aos y los sistemas de archivos estn claramente desarrollados para aprovechar sus detalles fsicos y lgicos, el uso de los dispositivos
de estado slido apenas est despegando en la ltima dcada. Y si bien esta primer aproximacin que nos permite emplear esta tecnolog transparentemente
es suficientemente buena para muchos de los usos bsicos, sin duda hay espacio para mejorar. Este es un tema que seguramente brinda amplio espacio para
investigacin y desarrollo para los prximos aos.

8.

Manejo avanzado de volmenes

En la seccin Plasmando la estructura en el dispositivo presentamos muy escuetamente al concepto de volumen. Mencionamos que un volumen tpicamente
coincide con una particin, aunque no siempre es el caso Y no profundizamos
ms al respecto. En esta seccin describiremos uno de los mecanismos en que podemos combinar diferentes dispositivos fsicos en un slo volumen, y cmo bajo
las diferentes modalidades que presentaremos lleva a ganar en confiabilidad,
rendimiento y espacio disponible.
Abordaremos un esquema llamado RAID, Arreglo Redundante de Discos Baratos (Redundant Array of Inexpensive Disks)36 , propuesto en 1988 por David
Patterson, Garth Gibson y Randy Katz ante el diferencial que se presentaba (y
se sigue presentando) entre el avance en velocidad y confiabilidad del cmputo
en relacin al almacenamiento magntico. Bajo los esquemas RAID queda sobreentendido que los diferentes discos que forman parte de un volumen son del
mismo tamao. Si se remplaza un disco de un arreglo por uno ms grande, la
capacidad en exceso que tenga ste sobre los dems discos ser desperdiciada.
Por muchos aos, los arreglos RAID se hacan a travs de controladores dedicados, presentndose como un dispositivo nico al sistema operativo. Hoy en
da, prcticamente todos los sistemas operativos incluyen la capacidad de integrar varias unidades independientes en un arreglo por software; esto conlleva
un impacto en rendimiento, aunque muy pequeo. Hay tambin, y abordaremos algunas de estas implementaciones hacia el final de esta seccin, varias
implementaciones derivadas de RAID que han incorporado conceptos de capas
superiores en algunos sistemas operativos modernos.
RAID no es un slo esquema, sino que es un conjunto de esquemas, cada uno
de ellos diseado para mejorar distintos aspectos del almacenamiento en discos.
Veamos las caractersticas de los principales niveles en uso hoy en da.

8.1.

RAID 0: Divisin en franjas

Este esquema nos brinda una mejora tanto en espacio total, dado que presenta a un volumen grande en vez de varios discos probablemente ms pequeos,
36 Ocasionalmente se presenta a RAID como acrnimo de Arreglo Redundante de Discos
Independientes (Redundant Array of Independent Disks)

57

simplificando la tarea del administrador, como de velocidad, dado que las lecturas y escrituras al volumen ya no estarn sujetas al movimiento de una sola
cabeza, sino que habr una cabeza independiente por cada uno de los discos que
tengamos en el volumen.

Figura 23: Cinco discos organizados en RAID 0

Los discos que participan en un volumen RAID 0 no son sencillamente concatenados, sino que los datos son divididos en franjas (en ingls, el proceso se
conoce como striping, de la palabra stripe, franja; algunas traducciones al espaol se refieren a este proceso como bandeado). Esto hace que la carga sea
repartida de forma uniforme entre todos los discos, y asegura que todas las
transferencias mayores al tamao de una franja provengan de ms de un disco
independiente.

Figura 24: Divisin de datos en franjas

La confiabilidad del volumen, sin embargo, disminuye respecto a si cada uno
de los discos se manejara por separado: Basta con que uno de los discos presente
daos para que la informacin contenida en el volumen se pierda.
Puede construirse un arreglo bajo RAID nivel 0 con un mnimo de dos discos.

8.2.

RAID 1: Espejo

Este nivel est principalmente orientado a aumentar la confiabilidad de la

informacin: Los datos son grabados de forma simultnea e idntica en todos
los discos que formen parte del volumen. El costo de mantener los datos en
espejo, claro est, es el del espacio empleado: En su configuracin habitual, de
dos discos por volumen, el 50 % del espacio de almacenamiento se pierde por
fungir como respaldo del otro 50 %.

58

La velocidad de acceso a los datos bajo RAID 1 es mayor a la que tendramos

con un disco tradicional: Basta con que obtengamos la respuesta de uno de los
discos; el controlador RAID (sea el sistema operativo o una implementacin en
hardware) puede incluso programar las solicitudes de lectura para que se vayan
repartiendo entre ambas unidades. La velocidad de escritura se ve levemente
reducida, dado que hay que esperar a que ambos discos escriban la informacin.

Figura 25: Dos discos organizados en RAID 1

Un arreglo RAID nivel 1 se construye tpicamente con dos discos.

8.3.

Los niveles 2, 3 y 4 de RAID

Los siguientes tres niveles de RAID combinan propiedades de los primeros

junto con un algoritmo de verificacin de integridad y correccin de errores.
Estos han cado casi por completo en el desuso dado que los otros niveles, y
muy en particular el nivel 5, ofrecen las mismas caractersticas, pero con mayor
confiabilidad

8.4.

RAID 5: Paridad dividida por bloques

El nivel 5 de RAID proporciona un muy buen equilibrio respecto a las caractersticas que venimos mencionando: nos brinda el espacio total de almacenamiento de todos los discos que formen parte del volumen menos uno. Para cada
una de las franjas, RAID5 calcula un bloque de paridad. Ahora, este bloque de
paridad no siempre va al mismo disco, sino que se va repartiendo entre todos
los discos del volumen, desplazndose a cada franja, de modo que cualquiera de
los discos puede fallar, y el arreglo continuar operando sin prdida de informacin. Esta falla se notifica al administrador del sistema, quien debe reemplazar
el disco lo ms pronto posible (dado que, de no hacerlo, la falla en un segundo
disco resultar en la prdida de toda la informacin).
Dependiendo de la configuracin, la velocidad de acceso de este nivel puede
ser es ligeramente menor que la que obtendramos de los discos sin RAID, o
ligeramente menor a la que obtendramos con RAID nivel 0. Dado que la electrnica en los discos actuales nos notificar explcitamente en caso de fallo de
lectura, al leer informacin podemos leer nicamente los discos que contengan
la informacin (e ignorar al de paridad); si nuestro RAID est configurado para
verificar la paridad en lecturas, claro est, todas las lecturas tendrn que obtener
la franja correspondiente de todos los discos del arreglo para poder calcularla.

59

Figura 26: Divisin de datos en franjas, con paridad, para RAID 5

Las escrituras son invariablemente ms lentas que lo que obtenemos tanto
en ausencia de RAID como en niveles 0 y 1, dado que siempre tendr que
recalcularse la paridad; en el caso de una escritura mnima, menor a una franja,
tendr que leerse la franja entera de todos los discos participantes en el arreglo,
recalcularse la paridad, y grabarse en el disco correspondiente.
Cuando uno de los discos falla, el arreglo comienza a trabajar en el modo
interino de recuperacin de datos (Interim data recovery mode), en el que todas
las lecturas involucran a todos los discos, ya que tienen que estar recalculando
y rellenando la informacin que provendra del disco daado.

Figura 27: Cinco discos organizados en RAID 5

Para implementar RAID nivel 5 son necesarios por lo menos 3 discos, aunque
es comn verlos ms anchos, pues de este modo se desperdicia menos espacio
en paridad. Si bien tericamente un arreglo nivel 5 puede ser arbitrariamente
ancho, en la prctica es muy raro ver arreglos con ms de 5 discos: Tener un
arreglo ms ancho aumentara la probabilidad de falla. Si un arreglo que est
ya operando en el modo interino de recuperacin de datos se encuentra con una
falla en cualquiera de sus discos, tendr que reportar un fallo irrecuperable.

8.5.

RAID 6: Paridad por redundancia P+Q

Se trata nuevamente de un nivel de RAID muy poco utilizado. Se basa en el

mismo principio que el de RAID 5 pero, empleando dos distintos algoritmos para
calcular la paridad, permite la prdida de hasta dos de los discos del arreglo.
La complejidad computacional es sensiblemente mayor a la de RAID 5, no slo
porque se trata de un segundo clculo de paridad, sino porque este clculo debe
hacerse empleando un algoritmo distinto y ms robusto Si bien para obtener
60

la paridad P basta con hacer una operacin XOR sobre todos los segmentos
de una franja, la segunda paridad Q tpicamente emplea al algoritmo ReedSolomon, paridad diagonal o paridad dual ortogonal. Esto conlleva a una mayor
carga al sistema, en caso de que sea RAID por software, o a que el controlador
sea de mayor costo por implementar mayor complejidad, en caso de ser hardware
dedicado.

Figura 28: Cinco discos organizados en RAID 6

El nivel 6 de RAID puede implementarse con 4 o ms unidades, y si bien el
espacio dedicado a la redundancia se incrementa a dos discos, la redundancia
adicional que ofrece este esquema permite crear volmenes con un mayor nmero
de discos.

8.6.

Niveles combinados de RAID

Viendo desde el punto de vista de la abstraccin presentada, RAID toma una

serie de dispositivos de bloques y los combina en otro dispositivo de bloques.
Esto significa que puede tomarse una serie de volmenes RAID y combinarlos
en uno solo, aprovechando las caractersticas de los diferentes niveles.
Si bien pueden combinarse arreglos de todo tipo, hay combinaciones ms
frecuentes que otras. Con mucho, la ms popular es la de los niveles 1 + 0
Esta combinacin, frecuentemente llamada sencillamente RAID 10, ofrece un
mximo de redundancia y rendimiento, sin sacrificar demasiado espacio.
Con RAID nivel 10 creamos volmenes que suman por franjas unidades
en espejo (un volumen RAID 0 compuesto de varios volmenes RAID 1). En
caso de fallar cualquiera de las unidades del arreglo, sta puede ser reemplazada
fcilmente, y su reemplazo no significar un trabajo tan intensivo para el arreglo
entero, slo para su disco espejo.
Bajo este esquema, en el peor de los casos, en un volumen con n discos fsicos
tendramos n2 volmenes nivel 1, y por tanto podramos soportar la prdida de
hasta n2 discos Siempre que estos no formen parte de un mismo volumen nivel
1.
Ahora bien, esta combinacin nos ilustra cmo el rden de los factores s altera el producto: Si en vez de la concatenacin de varias unidades espejeadas (un
61

Figura 29: Seis discos organizados en RAID 1+0

volumen nivel 0 compuesto de varios volmenes nivel 1) armramos nuestro arreglo en rden inverso, esto es, como el espejeo de varias unidades concatenadas
por franjas, parecera que obtenemos los mismos beneficios Pero analizando
lo que ocurre en caso de falla, resulta claro que el nivel de redundancia resulta
mucho menor.
En este caso, nuestro arreglo soportar tambin el fallo de hasta n2 de sus
discos, pero nicamente si ocurren en el mismo volumen del espejo. Si se perdieran al mismo tiempo el disco 1 (del subvolumen 1) y el disco 5 (del subvolumen
2), tendramos prdida de datos.

8.7.

Ms all de RAID

Los esquemas RAID vienen, sin embargo, de fines de la dcada de 1980, y en

los ms de 20 aos desde que fueron planteados, si bien han cambiado el panorama del almacenamiento, han sido ya superados. En nuestro caso, profundizamos
en estos esquemas y no los desarrollos posteriores dada la limpieza conceptual
que presentan, y dado que otros esquemas incluso hacen referencia al nivel de
RAID que estaran reemplazando en su documentacin.
Varios sistemas operativos ofrecen hoy el concepto de un gestor de volmenes lgicos: Una interfaz que permite, como dos pasos independientes, agregar
diferentes volmenes fsicos a un

62

Figura 30: Seis discos organizados en RAID 0+1

9.

Otros recursos
Practical File System Design (Dominic Giampaolo, 1999): El autor fue
parte del equipo que implement el sistema operativo BeOS, un sistema
de alto rendimiento pensado para correr en estaciones de alto rendimiento,
particularmente enfocado al video. El proyecto fracas a la larga, y BeOS
(as como BeFS, el sistema que describe) ya no se utilizan. Este libro tiene
una muy buena descripcin de varios sistemas de archivos, y aborda a
profundidad tcnicas que hace 15 aos eran verdaderamente novedosas, y
hoy forman parte de casi todos los sistemas de archivos con uso amplio, e
incluso algunas que no se han logrado implementar y que BeFS s ofreca.
FAT Root Directory Structure on Floppy Disk and File Information (Mufti
Mohammed, Codeguru, 2007)
File Allocation Table - 16bit (Peter Clark)
A Fast File System for UNIX (Marshall Kirk Mckusick, William N. Joy,
Samuel J. Lefler, Robert S. Fabry, 1984)
The Design and Implementation of a Log-Structured File System (Mendel
Rosenblum, J. K. Ousterhout, 1992)
The Second Extended File System: Internal Layout (Dave Poirier, 20012011)
NILFS2 en Linux (Csar Yez)
Los discos desde la perspectiva de un sistema de archivos (Csar Yez)
A hash-based DoS attack on Btrfs (LWN)
Denial-of-Service Attack Found In Btrfs File-System (Slashdot)
63

Default /etc/apache2/mods-available/disk_cache.conf is incompatible with

ext3 (bug de Debian ilustrando los lmites en nmeros de archivos para
Ext3)
The Design and Implementation of a Log-Structured File System (John
K. Ousterhout, Mendel Rosenblum, 1992)
File-system development with stackable layers (Heidemann y Popek, 1994
ACM Transactions on Computer Systems)
Serverless network file systems (Thomas E. Anderson et. al., 1996, ACM
Transactions on Computer Systems)
LogFS Finally a scalable flash file system (Jrn Engel, Robert Mertens,
2005)
Log-structured file systems: Theres one in every SSD (Valerie Aurora,
2009)
JFFS2, UBIFS, and the growth of flash storage (Neil Brown, 2012)
A case for Redundant Arrays of Inexpensive Disks (Patterson, Gibson,
Katz 1988)
Unidades de estado slido. El reto de la computacin forense en el mundo
de los semiconductores (Cano Martinez, 2013)
Non-volatile memory based on the ferroelectric photovoltaic effect (Guo,
You, Zhow et. al., 2013)
eMMC/SSD File System Tuning Methodology, Cogent Embedded, 2013
(referido desde A flash filesystem tuning guide, LWN, julio 2013)
OpenPlanets Results Evaluation Framework, Open Planets Foundation.
Muestra la evolucin a lo largo de los aos de cmo reconocen archivos
de tipos conocidosvarias herramientas (para reconocimiento de tipo de
archivos)

64