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
Boot
block

Superblock Espacio libre
Inodes
Dir. Root Archivos y
directorios
Cada partición






Partición Partición 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



Abrir





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.
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…



En forma general




Controlar quien tiene acceso a qué archivo
Controlar el tipo de acceso que un usuario puede realizar
sobre archivo
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
principales
/etc/passwd /home/juan
/home/otro
root
rw
rw
rw
juan
r
rw
r
otro
r
r
ACL
r
capacidad
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
table
memory-resident
i-node table
file offset
file offset
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


Bloques de disco son asignados aleatoriamente a
archivos sistema usado por largo tiempo


Metadata al principio en disco
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


En lugar de varias escrituras asincrónicas


Escritura eficiente
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
archivo2
archivo1
inode
directorio
dir1
dir2
FFS
dir1
Map inode
dir2
Log
archivo1
datos
archivo2
LFS
2 archivos de 1 bloque:
dir1/archivo1
dir2/archivo2
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
Descargar

Sistema de Archivos