Sistemas de Archivos Cecilia Hernndez 2007 1 Sistemas

Sistemas de Archivos Cecilia Hernández 2007 -1

Sistemas de Archivos ¢ Concepto simple l Implementa abstracción para accesar almacenamiento secundario • Abstracción : archivos l Proporciona organización lógica para accesar archivos en directorios • Normalmente directorio implementado como árboles l 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 l ¢ Contenido, tamaño, dueño, última fecha de modificación, protección, etc Archivos pueden tener tipos entendibles l l 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 l l 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 l l ¢ Ú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 l l l 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 l 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 l Administración de disco • Como organizar colección de bloques de discos en archivos l 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 l Protección • Como se protege la información de archivos en el sistema entre distintos usuarios y sistema l 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 l 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 l Tabla de Particiones • Tabla con información acerca de cada partición l Estructura de directorios • Tabla de directorios accesados recientemente con su información l 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 l 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 l l l ¢ 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) l l 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 l 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 l Una partición: grupo de cilindros adyacentes l 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 l Sabe de boot loader y tabla de particiones Tabla de partición l Define direcciones de inicio y fin de cada partición l Una partición es marcada como activa Cuando sistema sube l BIOS ejecuta 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 l SOs y sistemas de archivos pueden ser usados en forma independiente l • Respaldos o cualquier uso que quiera darle el usuario

Crear, Abrir y Usar un Archivo ¢ Crear l l ¢ Abrir l l ¢ 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 l l 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 l l Define tamaño de bloque, en general entre 1 KB y 4 KB 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 l l 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 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 l l ¢ Primer sector de bloque en disco Tamaño de archivo en términos de número de sectores Ventajas/Desventajas l l + 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 l 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 l ¢ Rápido para archivos pequenos y permitir archivos grandes Encabezado de archivo posee 13 punteros l l l 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 1 KB. Calcule: l Máximo tamaño de archivo posible l 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. l l l l Archivo directorio “/” contiene lista archivos/directorio con sus Inodos Directorio “home” tiene 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 l 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 l 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 l 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 l 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… l l ¢ En forma general l ¢ 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 l l 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 l Listas de control de acceso (ACLs) • Para cada objeto, guardar una lista de los principales y las acciones permitidas para principales l Capacidades • Para cada principal, guardar una lista de los objetos y acciones permitidas para principales l 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 l l ¢ Como llaves (caso casa) Facilitan compartición ACLs son más fáciles de manejar l 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 l Esquema puede simplificarse agrupando • Poner usuarios en grupos, poner grupos en ACLs l 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 l 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 l l 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 l 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” l l 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, l 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 open file table memory-resident i-node table file offset

Algunos SAs populares ¢ ¢ ¢ NTFS (Windows) Minix (No se usa tanto, pero disponible) UFS Ext 2 fs: Ext 2 (linux) estandar, basado en inodos, incluye ideas de FFS Ext 3 fs: Ext 3 (linux). Journaling. Basado en ext 2 fs Veritas. FS (Vx. FS) HP-UN. Journaling Reinser. FS (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 l Larga lista de sistemas de archivos

UFS (Sistema de Archivos Unix original) ¢ Layout en disco de UFS l ¢ Bloques de disco son asignados aleatoriamente a archivos sistema usado por largo tiempo l ¢ 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) l l 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 4 KB l l 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 l l l ¢ 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 l l 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 l 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 l 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 l ¢ Veritas. FS, Ext 3, Reinser. FS, XFS, ntfs Idea básica l Actualizar metadatos y datos transaccionalmente • Los dos o ninguno l 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 l l ¢ En buffer cache En disco Idea básica de solución l l l 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 l 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 l Acción de Commit incluye escribir registro redo

Si ocurre caida de sistema ¢ ¢ Recupera Log Redo transacciones committed l l ¢ 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 l Ignorarlas • Como si caida ocurriera antes de commit

Desempeño ¢ Log es una escritura continua l ¢ En lugar de varias escrituras asincrónicas l ¢ Escritura eficiente Costosas en términos de desempeño Journaling l l Bueno, eficiente Manejo de consistencia y recuperación eficiente

Detalles sobre buffer cache ¢ ¢ Compartido por todos los procesos Utiliza algoritmo de reemplazamiento l ¢ ¢ ¢ Típicamente LRU Incluso una cache pequeña puede ser efectiva (4 MB) 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 l 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 l Mantener consistencia es cara Algunos enfoques l “Write through” lo que se escribe en buffer cache se escribe en disco (escritura sincrónica) l “Write behind” mantener cola de bloques no escritos, periodicamente escribir en disco (no es confiable) l 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 l l l 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 l l 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 l 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) l Presente en SO Net. BSD • Aparece en 1993 en Open. BSD • 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 archivo 2 archivo 1 inode directorio dir 1 dir 2 FFS dir 1 Map inode dir 2 Log archivo 1 datos archivo 2 LFS 2 archivos de 1 bloque: dir 1/archivo 1 dir 2/archivo 2

Desafíos y soluciones ¢ Ubicando datos en el log l l 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 l l 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 l l l 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 l 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 l l 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