Sistemas de

Archivos
Cecilia Hernández
2007-1
Sistemas de Archivos

 Concepto simple
 Implementa abstracción para accesar
almacenamiento secundario
• Abstracción : archivos
 Proporciona organización lógica para
accesar archivos en directorios
• Normalmente directorio implementado como
árboles
 Proporciona a usuarios mecanismos de
protección y compartición de archivos
• Debe proporcionar semántica de consistencia para
permitir acceso compartido
Archivos

 Archivo es una colección de datos con algunas

propiedades
 Contenido, tamaño, dueño, última fecha de
modificación, protección, etc
 Archivos pueden tener tipos entendibles
 Sistema de archivos: archivo simple, directorio,
enlace
 Otras partes del SO, aplicaciones o bibliotecas
• Ejecutable, biblioteca, código fuente, etc
 Típicamente, tipos pueden incluidos en nombre
 En Windows, tipo incluido en nombre
 En unix, tipo especificado en los dos primeros bytes
del archivo (magic numbers) o caracteres iniciales
Operaciones sobre archivos

 create(name)
 open(name, mode)
 read(fd, buf, len)
 write(fd, buf, len)
 sync(fd)
 seek(fd,pos)
 close(fd)
 unlink(name)
 rename(old, new)
Directorios

 Organizar archivos en sistema

 Útil para usuarios
 Útil para sistema de archivos y usuarios
para buscar y accesar archivos
 Mayoría de sistemas de archivos soportan
múltiples niveles de directorios
 Con jerarquía de nombres
 Mayoria soport directorio actual y anterior
 Rutas absolutas y relativas
• $cd /home/alumnos/pedro (absoluto)
• $cd tareas (relativo a dir actual)
Implementación directorios

 Normalmente un directorio es sólo un

archivo con metadata
 con lista de archivos y atributos
contenidos en actual directorio
• Lista (nombre archivo, atributos archivo)
• Atributos pueden ser
• Tamaño, protección, dueño, tiempo de
creación, tiempo de última modificación,
ubicación en disco, etc
 Implementación de Sistemas de
Archivos
 Componentes de SA
 Administración de disco
• Como organizar colección de bloques de discos en archivos
 Nombres
• Usuarios identifican sus archivos mediante nombres,
abstrayéndose de como se almacenan internamente (#cilindro,
pista y sectores). Uso de nombres para archivos y directorios
 Protección
• Como se protege la información de archivos en el sistema entre
distintos usuarios y sistema
 Confiabilidad/durabilidad/Rendimiento
• Cuando sistema se cae, se pierde información en Memoria
(caches), pero se desea que información de archivos no se
pierda
 Implementación de Sistemas de
Archivo
 Estructuras en Disco y Memoria para implementar SA
 En disco
• Bloque Control de Buteo (Boot Control Block)
• Información para butear SO de partición (si existe en
partición). Unix : Boot block, NTFS : Partition Block Sector
• Bloque de Control de Partición (Partition Control Block)
• Detalles de partición: Tamaño bloque, contador y
punteros de bloques libres, contador y punteros de FCBs.
Unix Superblock, NTFS : Tabla de Archivo Maestra
(Master File Table). En Unix/linux llamado superblock
• Estructura de Directorios a usar
• FCB (File Control Block)
• Contiene información de archivo: dueño, tamaño,
permisos, punteros a bloques de disco, etc
• Unix Inodo, NTFS, info guardada en Tabla de Archivo
Maestra
 Implementación de Sistemas de
Archivos cont.

 Estructuras en Memoria
 Tabla de Particiones
• Tabla con información acerca de cada partición
 Estructura de directorios
• Tabla de directorios accesados recientemente con su
información
 Tabla de Archivos Abiertos a nivel de Sistema (TAAS)
• Contiene copia de los FCBs de cada archivo, y otra informacion
como número de Procesos que tiene archivo abierto
 Tabla de Archivos Abiertos a nivel de Proceso (TAAP)
• Contiene puntero a entrada a tabla de archivos abiertos de
sistema
 Particiones de disco
Caso Unix/linux
MBR T particiones Partición Partición Partición

Boot Superblock Espacio libre Inodes Dir. Root Archivos y

block directorios

 Cada partición
 boot block, puede subir sistema cargando programa residente
aqui
 Superblock. Especifica los límites de las áreas siguientes,
contiene punteros a listas de inodos libres y bloques de archivos
libres
 Area de inodos. Contiene descriptores (inodos) para cada archivo
en el disco. Todos los inodes son del mismo tamaño
 Dir root. Inodo y directorio root
 Archivos y directorios. Bloques de se usan para
 Una partición puede usarse para un sistema de archivos o como
area de swapping ( en este caso es sólo bloques para respaldo)
Proceso de buteo
Caso Unix/linux
 CPU ejecuta código residente en ROM BIOS (Read
Only Memory Basic Input Output System)
 Código verifica y prepara HW de sistema
 Carga programa (master boot program o boot
loader) ubicado en sector 0 (Master Boot Record) de
disco
• En linux puede ser lilo o grub, los que permiten elegir
una partición a subir
• Contiene programa ejecuta SO en partición
• Estos boot loaders están en MBR o en primer sector
de parcición activa
 Con programas Lilo o Grub es posible definir varias
particiones con diferentes SOs
• Aunque tambien sirven para usar el mismo sistema
de archivos pero identificar diferentes SO (asociados
a diferentes linux kernels)
 Sistema de Archivos Unix (UFS)
 Sistema de Archivos original en Unix (1970)
 Disco dividido en particiones
 Una partición: grupo de cilindros adyacentes
 Un sistema de archivos puede residir en una partición
 BIOS define sector de buteo (boot sector) para estar en cabeza
0, cilindro 0, sector 1
 Master Boot Record (MBR) usado para butear computador
 Sabe de boot loader y tabla de particiones
 Tabla de partición
 Define direcciones de inicio y fin de cada partición
 Una partición es marcada como activa
 Cuando sistema sube
 BIOS ejecuta MBR
 MBR localiza partición activa y ejecuta bloque de buteo
Para que usar particiones?

 Dividir el disco para diversos

propósitos
 Tener diversos SOs cargados uno en
cada partición
 SOs y sistemas de archivos pueden
ser usados en forma independiente
• Respaldos o cualquier uso que quiera
darle el usuario
 Crear, Abrir y Usar un Archivo

 Crear
 SO busca en bloque de control de partición por un puntero de un
FCB no usado
 SO suma puntero de FCB en la estructura del directorio.
 Abrir
 Buscar si archivo esta abierto en TAAS, si no esta Buscar en
directorios por nombre de archivo
 Copiar información de FCB a la TAAS
 Sumar una entrada para el archivo en la TAAP, que contiene puntero
a TAAS
 SA retorna descriptor de archivo o handle a proceso que lo abre
 Usar
 Escribir, buscar el bloque de control de partición por punteros a
bloques de disco vacíos
 Leer. buscar en FCB bloques a leer
 Usando Disco para Almacenar
Archivos

 SA almacena archivos en bloques

 Define tamaño de bloque, en general entre 1KB y 4KB
 Existe un “Bloque Maestro” que define la ubicación del directorio root
• Siempre una ubicación bien conocida
• En general replicada para proporcionar mayor disponibilidad
 Posee una lista con bloques libres y bloques ocupados
• En general, bitmap, define un bit por bloque de disco
• 1 si esta ocupado, 0 si esta libre
• Almacenada en disco y en memoria (para aumentar
rendimiento)
 SO usa Caching
• SO mantiene cache con bloques de disco usados mas
recientemente (disminuir latencia de acceso a disco)
 Registro de Bloques Asignado a
Archivos

 Estructura de datos común

 Encabezado de archivo: cada archivo posee uno
• Que bloques de disco estan siendo ocupados por
archivo
 Distintas implementaciones: Como se sabe que bloques
pertenecen a que archivos
• Asignación contigua
• Archivos enlazados
• Archivos indexados
• Archivos indexados en múltiples niveles
 Asignación Contigua

 Usuario dice por adelantado tamaño de archivo

 SO busca en bitmap (usando criterio) bloques de
disco que satisfacen requerimiento de usuario
 El encabezado de archivo posee
 Primer sector de bloque en disco
 Tamaño de archivo en términos de número de
sectores
 Ventajas/Desventajas
 + Acceso secuencial rápido
 + Acceso aleatorio fácil
 - Fragmentación externa
 - Difícil cuando archivo crece más de lo definido
originalmente
 Archivos Enlazados
 Cada bloque de disco incluye puntero al siguiente bloque
de disco
 Encabezado de archivo posee dirección del primer bloque
de disco
 Ventajas/Desventajas
• + Archivos pueden crecer dinámicamente
• - Acceso secuencial no es tan bueno, pero mejor que aleatorio
• Requiere tiempo de búsqueda de próximo bloque
• - Acceso aleatorio muy lento
• - No es confiable, que pasa si se pierde o se estropea un
bloque?
 MS-DOS FAT (File Allocation Table) usa esta filosofía,
pero implementación mediante una tabla
 Mejor rendimiento, sobretodo si tabla esta en memria
 Archivos Indexados

 Usuario especifica tamaño máximo de archivo

 SA define un arreglo de punteros a bloques acorde al
tamaño máximo
 Encabezado de archivo posee arreglo de punteros de
bloques (index block: contiene punteros a los bloques de
disco del archivo)
 Ventajas/Desventajas
• + Tamaño de archivo puede crecer fácilmente hasta máximo
• + Acceso aleatorio es rápido
• - Costoso si archivo crece sobre máximo
• - Acceso secuencial lento, ya que bloques pueden estar
distantes unos de otros en disco
 Archivos Indexados con Múltiples
Niveles
 Objetivo
 Rápido para archivos pequenos y permitir archivos grandes
 Encabezado de archivo posee 13 punteros
 Tabla de punteros de tamaño fijo, aunque no son todos
equivalentes
 Primeros 10 (ahora 12) punteros direcccionan bloques de datos
 Puntero décimo primero (11) (ahora 13): Puntero indirecto
• Apunta a bloque de punteros de bloques de datos
 Puntero décimo segundo (12) (ahora 14): Puntero doblemente
indirecto
• Apunta a bloque de punteros, los que a su vez contienen
punteros a bloques de datos
 Puntero décimo tercero (13) (ahora 15): Puntero triplemente
indirecto
• Apunta a bloque de punteros, los que a su vez contienen
punteros a bloques de punteros, los que contienen punteros a
bloques de datos
 Archivos Indexados con Múltiples
Niveles

 Unix implementa este mecanismo

 Ventajas/Desventajas
• + Simple
• + Archivos pueden crecer fácilmente (tamaño max
relativamente grande)
• + Archivos pequeños rápidos
• - Archivos grandes penalizados en tiempo de
búsqueda, por el uso de indirección de múltiples
niveles
• - Mucho tiempo usado en búsqueda de bloques
(cuando archivos son grandes)
 Ejemplo FAT

 Entrada directorio
test.txt ........... 88

20 35

25 103

35 25

88 20
95 0

103 EOF
 Ejemplo Inodos Unix (también en
FFS)

 Inodo estructura de datos que contiene dueño archivo, modo,

tamaño, protección, contadores de enlaces y tabla de asignación de
bloques de disco
 Ejemplo Inodos

 En el SA Unix, con archivos indexados con multiples niveles,

con encabezado de archivo de 13 entradas, 10 entradas para
direccionar bloques directamente, 1 entrada indirecta, 1 entrada
doblemente indirecta y 1 triplemente indirecta. Si el tamaño de
bloque es de 1KB. Calcule:
 Máximo tamaño de archivo posible
 Número de accesos a disco son necesarios para
alcanzar bloque 23, cuales son?
Ejemplo con i-nodos y búsqueda en
directorios
 Ejemplo Traducción Rutas con
Inodos
 Archivos directorios: archivos en que cada entrada contiene
archivo o directorio y además Inodo donde esta ubicado
 Archivo /home/juan/tarea.txt.
 Archivo directorio “/” contiene lista archivos/directorio con sus Inodos
 Directorio “home” tiene Inodo 100
 Inodo 100 contiene puntero a bloques donde esta “home”: bloque
200
 Bloque 200 : archivo directorio “home” posee inodo para “juan”:
inodo 110
 Inodo 110 contiene puntero a bloques donde esta “juan”: bloque 300
 Bloque 300 : archivo diretorio “juan” posee inodo para “tarea.txt”:
inodo 120
 Inodo 120 contiene punteros a bloques donde esta “tarea.txt”:
bloques 400, 401 y 402
 Ubicación de inodos

 Unix original tenía dos problemas de desempeño

importantes
 Bloques de datos en cualquier parte del disco
• Cuando archivo es nuevo se buscan bloques de archivos
• Cuando SA envejece y se llena necesita ubicar nuevos
archivos mientras otros han sido borrados
• Archivos de diferentes tamaños
• Bloques para archivos nuevos empiezan a estar dispersos en el
disco
 Inodos están ubicados lejos de los bloques de disco
• Todos los inodos al inicio del disco y luego los bloques de disco
• Búsqueda de archivos en directorios requiere referencias a
inodos y bloques de disco, como estan lejos unos de otros más
tiempo es requerido para su acceso
 Mejorando desempeño

 Uso de Buffer cache

 Explotar localidad usando memoria como cache para
archivos
• Cache es compartida por todos los procesos
• Muchos sistemas de archivos leen por adelantado (antes
que se necesite) a buffer cache
• Caching escrituras
• Necesario manejar consistencia en algunos casos se
requiere write-through
 Algunos problemas con el buffer cache
• Competencia de páginas con la administración de
memoria
• También requiere algoritmos de reemplazo
• Usualmente LRU
 Protección de archivos
 Protección usada para…
 Controlar quien tiene acceso a qué archivo
 Controlar el tipo de acceso que un usuario puede realizar
sobre archivo
 En forma general
 Generalizar archivos a objetos
 Generalizar usuarios a principales
 Generalizar lectura/escritura a acciones
 Un sistema de protección dice si una determinada
acción realizada por un determinado principal en un
deteminado objeto debería ser permitida
 Usuario dueño puede leer/escribir sobre archivo, pero no
otros
 Usuario puede leer algún archivo de sistema, pero no
escribirlo
 Modela para representar protección
 Dos maneras de verlo
 Listas de control de acceso (ACLs)
• Para cada objeto, guardar una lista de los principales y
las acciones permitidas para principales
 Capacidades
• Para cada principal, guardar una lista de los objetos y
acciones permitidas para principales
 Representación en siguiente matriz
objetos

/etc/passwd /home/juan /home/otro

root rw rw rw
principales juan r rw r
capacidad
otro r r r
ACL
ACLs y Capacidades
 Capacidades son más fácil de transferir
 Como llaves (caso casa)
 Facilitan compartición
 ACLs son más fáciles de manejar
 Basado en objetos, fácil de entregar y quitar
• Quitar capacidades es más difícil, hay que mantener
historia de principales que han tenido capacidad
• Difícil de seguir, pues principales se pueden pasar
capacidades
 ACLs se hacen grandes cuando objetos son muy
compartidos
 Esquema puede simplificarse agrupando
• Poner usuarios en grupos, poner grupos en ACLs
 Cambiando acciones sobre grupos afecta al grupo
completo
Consistencia del SA

 Los i-nodos y los bloques de discos residen en

buffer cache (memoria usada para cache de
archivos)
 El comando sync fuerza la escritura en disco
de la información de disco residente en
memoria
 Sistema hace un sync cada unos pocos
segundos
 Una caída del sistema o corte de energía entre
syncs puede dejar el disco inconsistente
 Se podría mejorar consistencia usando menos
caching pero esto perjudicaría el desempeño
Manejando consistencia de archivos
(i-cache)
 Verificar que cada bloque este asociado sólo
a un archivo
 Un vector de bits, un bit por cada bloque en disco
 Seguir la lista de bloques libres e inodos libres
• Cuando un bloque es encontrado, ver el bit
• Si bit == 0, ponerlo en 1
• Si bit == 1,
• Si bloque esta asociado a archivo y en lista de
bloques libres
• Eliminarlo de la lista de libres ( no garantia de
lo que suceda)
• Si bloque está asociado a dos archivos… error
Consistencia de directorios
(d-cache)

 Verificar que directorios formen un

árbol
 Verificar que el contador de links de
un archivo sea igual al número de
directorios que apuntan a archivo
 Compartiendo archivos 1
Enlaces duros
 Un archivo en Unix puede tener
múltiples nombres
 Nombre en entrada en el
directorio es llamado enlace
duro. Múltiples entrada en
directorio apuntan a mismo
inodo
 Cada inodo tiene un campo
“count” que indica el número de
enlaces duros
 Llamada a sistema
relacionadas “link” y “unlink”
 link(nombre existente, nuevo
nombre) crea nueva entrada en
directorio con nombre dado e
incrementa el count de inodo
 Unlink(nombre), destruye entrada en
directorio, decrementa count, si count
== 0 libera bloques de disco e inodo
ocupado por archivo
 Compartiendo archivos
Enlace simbólico
 Enlace simbólico entrada en
directorio que contiene
pathname a otro archivo en el
SA
 Llamada a sistema
 Symlink(nombre existente,
nuevo nombre)
 Asigna nuevo inodo a nuevo
archivo, nuevo archivo
contienen path de archivo
existente,
 Si antiguo archivo es
eliminado, accesar nuevo
archivo no será posible
 Compartición de archivos 2

 Cada usuario tiene una tabla de canal o tabla de archivos

abiertos por usuario
 Cada entrada en la tabla de archivos abiertos es un puntero a
una entrada a la tabla de archivos abiertos del sistema
 Cada entrada en la tabla de archivos abiertos contiene un file
offset y un puntero a una entrada en la tabla de inodos
residentes en memoria
 Si un proceso abre un archivo ya abierto se crea una nueva
entrada en la tabla de archivos abiertos con un nuevo file
offset apuntando a la misma entrada en la tabla de inodos
residentes en memoria
 Si un proceso hace un fork, el hijo obtiene una copia de la
channel table ( y luego el mismo file offset)
 Usuario 1 Usuario 2 Usuario 3

channel table channel table channel table

open file file offset file offset

table

memory-resident
i-node table
Algunos SAs populares

 NTFS (Windows)
 Minix (No se usa tanto, pero disponible)
 UFS
 Ext2fs: Ext2 (linux) estandar, basado en inodos, incluye
ideas de FFS
 Ext3fs: Ext3 (linux). Journaling. Basado en ext2fs
 VeritasFS (VxFS) HP-UN. Journaling
 ReinserFS (linux) Journaling con logging. Completamente
nuevo. Incluido en linux estandar
 JFS (de IBM). Journaling. Basado en otro
 FFS
 XFS (de SGI). Journaling. Basado en otro
 http://www.tldp.org/HOWTO/Filesystems-HOWTO.html
 Larga lista de sistemas de archivos
UFS (Sistema de Archivos Unix
original)
 Layout en disco de UFS
 Metadata al principio en disco
 Bloques de disco son asignados aleatoriamente a
archivos sistema usado por largo tiempo
 Cuando sistema nuevo, bloques asignados
secuencialmente a archivos
 Inodos lejos de bloques
Ubicación de inodos y bloques de
disco por archivo en UFS
 Inodo contiene metadata de archivo incluyendo direcciones
a bloques de disco
 Tiempo de búsqueda malo, cabeza debe moverse entre
cilindros distantes
FFS (Fast File System)

 Proyecto en Berkeley BSD FFS (1970)

 Idea es mejorar productividad y disminuir tiempo de
respuestas de Unix Original (UFS)
 Idea se basa en conocimiento de layout en disco
 Layout en disco en FFS
 Grupos de cilindros
 Tamaños de bloque de disco incrementado
de 512 bytes a 4KB
 Mejor soporte para archivos grandes
 Puede producir fragmentación interna
• Uso de fragmentos para solucionarla
 FFS
 FFS (File Fast System) usa idea de grupos de
cilindros
 Disco particionado en grupos de cilindros
 Bloques de datos de un mismo archivo ubicado en el
mismo grupo de cilindros
 Inodo de archivo ubicado en el mismo grupo de cilindros
 Introduce un requerimiento de espacio libre
 Para poder hacer lo explicado arriba se necesita tener
espacio libre disperso en todo el disco
 En FFS se reserva el 10 % del disco para estar
disponible
Sistemas de Archivos Journaling

 UFS y FFS usan memoria como cache para disco

(buffer cache)
 UFS y FFS tienen problemas cuando sistema se
cae
 Ejemplo caída de sistema en la creación de archivo
• 1 Asignación de inodo
• Apuntar en entrada de directorio inodo de archivo
• Problema de consistencia en estructuras de datos en
memoria y disco
 UFS y FFS proporcionan utilitarios para reconstruir
consistencia (fsck), pero muy lento
• Debe verificar cada bloque
• No escalable (más lento a medida que aumenta disco)
Sistemas de Archivos Journaling

 Se hicieron populares en 2002

 Varias opciones
 VeritasFS, Ext3, ReinserFS, XFS, ntfs
 Idea básica
 Actualizar metadatos y datos
transaccionalmente
• Los dos o ninguno
 En caso de falla, puede perderse un proco
de trabajo, pero disco queda consistente
• En forma precisa, consistencia mediante uso de
log o journal transaccional, en lugar de barrer
cada bloque de disco para verificar estado
 Almacenamiento de datos

 Datos
 En buffer cache
 En disco
 Idea básica de solución
 Siempre dejar copia de datos en estado
consistente
 Actualizar datos persistentemente escribiendo
secuencialmente (tiempo) en archivo journal
 En tiempo libre de sistema, hacer
actualizaciones escritas en journal
cronológicamente y liberar espacio de archivo
journal
Redo log

 Log
 Archivo que se escribe sólo al final conteniendo
registros de logs
• Start t
• Transacción t ha empezado
• T, x, v
• Transacción T ha actualizado bloque x y su nuevo valor
en v
• Puede loggear diferencia de bloques en lugar de
bloques
• Commit t
• Transacción T ha committed – actualización sobrevive
caida
 Acción de Commit incluye escribir registro redo
Si ocurre caida de sistema

 Recupera Log
 Redo transacciones committed
 Barre el log en orden y reejecuta
actualizaciones de las transacciones
committed
 Escrituras son idempotent (sólo ocurre una
vez independiente del número de veces
que se ejecute)
 Transacciones no committed
 Ignorarlas
• Como si caida ocurriera antes de commit
Desempeño

 Log es una escritura continua

 Escritura eficiente
 En lugar de varias escrituras asincrónicas
 Costosas en términos de desempeño
 Journaling
 Bueno, eficiente
 Manejo de consistencia y recuperación
eficiente
Detalles sobre buffer cache

 Compartido por todos los procesos

 Utiliza algoritmo de reemplazamiento
 Típicamente LRU
 Incluso una cache pequeña puede ser
efectiva (4MB)
 Hoy tenemos memorias grandes por lo que
podemos tener caches mas grandes
 Muchos sistemas de archivos leen por
adelantado a la cache, aumentando su
efectividad
Escrituras y lecturas en buffer cache

 Usuarios y aplicaciones asumen que datos están en disco

después de una escritura
 En realidad, no necesariamente, para eso se usa cache
 Sistema de archivos puede quedar inconsistente en caso de
falla si datos y metadatos no están consistentes en disco
 Mantener consistencia es cara
 Algunos enfoques
 “Write through” lo que se escribe en buffer cache se
escribe en disco (escritura sincrónica)
 “Write behind” mantener cola de bloques no escritos,
periodicamente escribir en disco (no es confiable)
 NVRAM: escribir en una RAM energizada y mas tarde en
disco (NVRAM es cara)
Lecturas vs escrituras

 Lecturas se ven beneficiadas con buffer

cache grandes
 Escrituras son un problema
 Cualquier estrategia debe incluir escritura a
disco en algún momento
 Luego tráfico a disco esta dominado por
escrituras
 Escribir inodos y bloques de datos incluye
movimiento de cabeza en disco (caro en
tiempo) y transferencia de datos.
 Log-Structured File System(LFS)
 Diseñado por avances en
 Discos grandes y creciendo cada año
 Disponibilidad de grandes memorias
• Buffer cache puede ser mas grande
• Puede manejar mas bloques de disco en Memoria
 Idea de LFS es tratar el disco como un log cuyas
operaciones se agregan en el tiempo
• Coleccionar escrituras en el buffer cache y escribir un conjunto de
escrituras al disco
• Toda la información escrita en disco se realiza en el log
• Recuperación en base a checkpoints (tratar el disco como bases
de datos)
 Presente en SO NetBSD
• Aparece en 1993 en OpenBSD
• Actual versión 3.1 (2006)
Idea LFS

 Usar disco como un log

 Si disco es manejado como log, no
habría costo de búsqueda
 Nuevos datos y metadatos (inodos y
directorios) son acumulados en buffer
cache, luego escritos todos al mismo
tiempo en bloques grandes
(segmentos de 0.5 M – 1 MB)
 Mejora utilización de disco
 Comparación entre FFS y LFS

archivo1 archivo2
inode

directorio

dir1 dir2
datos

FFS Map inode

dir1 dir2

2 archivos de 1 bloque:
Log dir1/archivo1
dir2/archivo2
archivo1 archivo2

LFS
 Desafíos y soluciones

 Ubicando datos en el log

 FFS pone los datos y metadatos en lugares conocidos en
el disco
 LFS escribe datos y metadatos al final del log
• LFS usa una map de inodos
• Mapea archivo con ubicación de inodo para archivo en un
lugar bien definido
 Manejando espacio libre en el log
 Disco es finito, luego log tambien es finito
 No se puede seguir agregando en log infinitamente
• Se necesita recuperar bloques borrados en parte antigua de
log
• Log organizado en segmentos grandes (0.5 – 1 MB)
• Cuando segmento se llena se escribe en disco
• Con el tiempo segmentos se fragmentan (nuevos y viejos
bloques)
• Segmentos con pocos datos válidos se recuperan
• Datos previamente copiados a final de log
LFS

 Problemas
 Su implementación no es tan simple
 Ubicando datos en log no es tan rápida
 Manejando espacio libre no es tan sencillo, no
siempre se puede agregar info, cuando se
elimina información deben recuperarse bloques
escritos previamente en log
• Manejo de fragmentación de segmentos y limpieza
es complicado
• Uso de demonio de limpieza encargado de verificar
fragmentación, compactación y recuperación
 Comparación entre FFS, JFS y LFS

 LFS y FFS
 Carga de trabajo por metadatos es cara
• Incluye escritura pequeñas (inodos ocupados y entradas
en directorios)
 Problema de limpieza de segmentos en LFS es un
problema
 LFS y JFS
 JFS es robusto como LFS, pero metadata debe ser
escrita en disco más frecuentemente
 No confundir JFS con LFS
• JFS tiene log de transacciones a disco para manejar
caidas y recuperación más rápido manejando
consistencia en disco asincrónicamente
• LFS el disco es visto como log