Sistema de Archivos

Slide 1: Sistemas de Archivos Cecilia Hernández 2007-1

Slide 2: 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

Slide 3: 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

Slide 4: 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) 

Slide 5: 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)

Slide 6: 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

Slide 7: 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

Slide 8: 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

Slide 9: 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

Slide 10: 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)

Slide 11: 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)

Slide 12: 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

Slide 13: 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

Slide 14: 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 

Slide 15: 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)

Slide 16: 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

Slide 17: 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

Slide 18: 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 

Slide 19: 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

Slide 20: 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

Slide 21: 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)

Slide 22: Ejemplo FAT Entrada directorio  test.txt ........... 88 35 20 103 25 25 35 20 88 0 95 EOF 103

Slide 23: 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

Slide 24: 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?

Slide 25: Ejemplo con i-nodos y búsqueda en directorios

Slide 26: 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

Slide 27: 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

Slide 28: 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

Slide 29: 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

Slide 30: 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 ACL

Slide 31: 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

Slide 32: 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

Slide 33: 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

Slide 34: 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

Slide 35: 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

Slide 36: 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

Slide 37: 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)

Slide 38: Usuario 1 Usuario 2 Usuario 3 channel table channel table channel table open file file offset file offset table memory-resident i-node table

Slide 39: Algunos SAs populares NTFS (Windows)  Minix (No se usa tanto, pero disponible)  UFS  Ext2fs: Ext2 (linux) estandar, basado en inodos  Ext3fs: Ext3 (linux). Journaling. Basado en otro  VeritasFS (VxFS). Journaling o logging  ReinserFS (linux) Journaling con logging. Completamente  nuevo. Incluido en linux estandar JFS (de IBM). Journaling o logging. Basado en otro  FFS  XFS (de SGI). Journaling o logging. Basado en otro  http://www.tldp.org/HOWTO/Filesystems-HOWTO.html   Larga lista de sistemas de archivos

Slide 40: 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 

Slide 41: 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

Slide 42: 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 

Slide 43: 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

Slide 44: 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

Slide 45: 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)

Slide 46: Sistemas de Archivos Journaling Se hicieron populares en 2002  Varias opciones  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

Slide 47: 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 cronologicamente y liberar espacio de archivo journal

Slide 48: 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 

Slide 49: 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

Slide 50: 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

Slide 51: 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

Slide 52: 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)

Slide 53: 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.

Slide 54: 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)

Slide 55: 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

Slide 56: Comparación entre FFS y LFS inode archivo2 archivo1 directorio datos dir1 dir2 Map inode FFS dir1 dir2 2 archivos de 1 bloque: Log dir1/archivo1 dir2/archivo2 archivo1 archivo2 LFS

Slide 57: 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

Slide 58: 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

Slide 59: 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