Tesis de grado de Ingeniería en informáticamaterias.fi.uba.ar/7500/TesisLeguizamo.pdf · Tesis de...

Tesis de grado de Ingeniería en informática

Sistemas de Archivos.Tendencias y mejoras tecnológicas

Universidad de Buenos Aires

Facultad de Ingeniería

Departamento de Computación

Tutor: Lic. Arturo Servetto

Tesista: Matías Leguizamo

Padrón: 82375

E-mail: [email protected]

ÍNDICE

Índice

1. Objetivo 5

2. Dedicatoria 6

3. Introducción 7

4. Relevamiento bibliográ�co sobre sistemas de archivos 84.1. Asignación de bloques a archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1.1. Asignación contigua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.1.2. Asignación por lista enlazada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1.3. Asignación por lista enlazada utilizando una tabla en memoria . . . . . . . . . . . . . . . . 94.1.4. Nodos-i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2. Administración de espacio libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2.1. Administración mediante mapa de bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2.2. Administración mediante lista enlazada de unidades de almacenamiento libres . . . . . . . . 12

4.3. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.4. Rendimiento del sistema de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.4.1. Uso de cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4.2. Lectura adelantada de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4.3. Reducción del movimiento del brazo del disco . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.5. Implementación de directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.6. Nuevas prestaciones en sistemas de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.6.1. Sistemas de archivos estructurados por registro . . . . . . . . . . . . . . . . . . . . . . . . . 154.6.2. Sistemas de archivos por bitácora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.6.3. Sistemas de archivos virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.7. Casos de estudio de sistemas de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.7.1. DOS (Disk Operating System) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.7.2. NTFS (New Technology File System) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.7.3. UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.7.4. EXT-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.7.5. EXT-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.7.6. EXT-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.7.7. HFS (Hierarquical File System): . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.7.8. HFS+ (HFS plus) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.7.9. HPFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.7.10. ZFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5. Relevamiento bibliográ�co de métodos y tendencias para optimizar el rendimiento de sis-temas de archivo 305.1. Fragmentación en sistemas de archivos y Principio de localidad . . . . . . . . . . . . . . . . . . . . 30

5.1.1. Fragmentación de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.2. Principio de localidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2. Desfragmentación y técnicas para reducir la fragmentación en sistemas de archivos actuales . . . . 315.2.1. Sistemas de archivos Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2.2. Sistemas de archivos archivos Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2.3. Sistema de archivos EXT-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2.4. Sistema de archivos EXT-4, HFS+, ZFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2.5. Ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3. Líneas de investigación sobre técnicas para evitar la fragmentación en sistemas de archivos modernos 335.3.1. Sistemas de archivos Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3.2. Sistemas de archivos NTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3.3. EXT-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.4. Bu�er-cache para la optimización de tiempos de acceso . . . . . . . . . . . . . . . . . . . . . . . . . 375.4.1. Bu�er-cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.4.2. Política de reemplazo de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

1 Tesis de grado de ingeniería en informática.

ÍNDICE

5.4.3. Sincronización para el reemplazo de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.4.4. Optimización en la performance del bu�er-cache por medio de algoritmos que utilizan in-

formación de la carga del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.4.5. Optimización en la performance del bu�er-cache por medio de mejoras en la política de

actualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.4.6. Colas múltiples de reemplazo para el segundo nivel de bu�er-cache . . . . . . . . . . . . . . 41

6. Elaboración de una propuesta de solución alternativa o superadora 446.1. Localidad de archivos asociados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1.1. Algoritmo de principio de localidad en archivos asociados . . . . . . . . . . . . . . . . . . . 446.1.2. Heurística para el algoritmo de principio de localidad en archivos asociados . . . . . . . . . 466.1.3. Método para evitar la fragmentación en archivos asociados . . . . . . . . . . . . . . . . . . 466.1.4. Resultado de la reubicación de archivos según las relaciones . . . . . . . . . . . . . . . . . . 46

6.2. Persistencia temporal de los accesos a archivos por los procesos . . . . . . . . . . . . . . . . . . . . 466.3. Depuración de la tabla histórica de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.4. Módulos que forman la solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4.1. Módulo que implementa el algoritmo del principio de localidad en archivos asociados . . . . 496.4.2. Módulo de merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.4.3. Módulo de reubicación de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.4.4. Módulo orquestador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.4.5. Heurística para la ejecución del módulo de orquestación . . . . . . . . . . . . . . . . . . . . 506.4.6. Mecanismo de log para mantener la consistencia en caso de falla . . . . . . . . . . . . . . . 516.4.7. Control de la concurrencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.4.8. Módulo de rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.4.9. Módulo de depuración de la tabla histórica de relaciones . . . . . . . . . . . . . . . . . . . . 526.4.10. Frecuencia de ejecución del módulo orquestador . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.5. Modi�caciones necesarias en Sistema de archivos NTFS para soportar esta técnica . . . . . . . . . 536.5.1. Cola compartida de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.5.2. Tabla histórica de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.5.3. Estructura utilizada para identi�cación de inconsistencias tras una falla . . . . . . . . . . . 546.5.4. Estructura utilizada para por el proceso de rollback . . . . . . . . . . . . . . . . . . . . . . 556.5.5. Modi�caciones generales en los Sistemas de archivos . . . . . . . . . . . . . . . . . . . . . . 56

7. Evaluación Analítica y Experimental de la Propuesta 577.1. Evaluación analítica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.1.1. Hipótesis sobre el tiempo de seek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.1.2. Hipótesis sobre el tiempo de latencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.1.3. Hipótesis sobre el tiempo de transferencia, . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.1.4. Expresión general del tiempo de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.1.5. Grá�co del tiempo de seek en función de la distancia entre cilindros . . . . . . . . . . . . . 587.1.6. Grá�co del tiempo de latencia en función de la distancia entre bloques . . . . . . . . . . . . 597.1.7. Observaciones �nales sobre el tiempo de acceso . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.2. Evaluación Experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.2.1. Descripción de la simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.2.2. Diagrama de arquitectura de la simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.2.3. Diagrama de secuencia de la simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.2.4. Código fuente de módulo FileSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.2.5. Código fuente de módulo TimesHelper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.2.6. Código fuente de módulo LocalityPrinciple . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.2.7. Código fuente de módulo CartesianProductHelper . . . . . . . . . . . . . . . . . . . . . . . 677.2.8. Código fuente de módulo Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687.2.9. Código fuente de módulo Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.2.10. Código fuente de módulo Orchestrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.2.11. Código fuente de módulo RandomBlockSelector . . . . . . . . . . . . . . . . . . . . . . . . . 717.2.12. Código fuente de módulo SecuentialBlockSelector . . . . . . . . . . . . . . . . . . . . . . . . 717.2.13. Análisis comparativos de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.2.14. Resumen de los resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89


ÍNDICE

8. Conclusión 908.1. Análisis de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908.2. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

9. Índice alfabético 92

10.Referencias 94


ÍNDICE

Imagine there's no Heaven It's easy if you try And no Hell below us Above us only sky

Imagine all the people Living for today Imagine there's no country It isn't hard to do

Nothing to kill or die for And no religion too Imagine all the people Living life in peace

You may say I'm a dreamer But I'm not the only one Maybe someday you will join us And the world will be as

one

Imagine no posessions I wonder if you can No need for greed or hunger Or Brotherhood of Man

Imagine all the people Sharing all the world You may say that I'm a dreamer But I'm not the only one

And maybe someday you will join us And the world will be as one

You may say that I'm a dreamer But I'm not the only one Maybe someday you will join us And the world will be

as one....

John Lennon, 1971


1 OBJETIVO

1. Objetivo

El objetivo del trabajo es analizar tendencias y puntos débiles de sistemas de archivos para plantear mejorasa alguno de estos aspectos; para esto, el trabajo se divide en cuatro etapas.

La primer etapa está dedicada a un relevamiento bibliográ�co y la confección de un informe sobre Sistemas deArchivo.

La segunda etapa se centra en un relevamiento bibliográ�co y la confección de un informe sobre tenden-cias tecnológicas para optimizar el rendimiento de los sistemas de archivo.

En la tercer etapa se elaborará el planteo de una propuesta de solución alternativa, superadora o comple-mentaria para atacar los problemas detectados.

La cuarta etapa consiste en la evaluación analítica y/o experimental de la propuesta.


2 DEDICATORIA

2. Dedicatoria

Este trabajo está dedicado a Vanesa (mi esposa) y a Tomy (mi hijo) que son las personas que me dan lasfuerzas necesarias para seguir adelante en esta carrera tan difícil y compleja. A vos Vane que estás a mi lado demanera incondicional desde que comencé la carrera y vos Tomy que me cambiaste la vida cuando naciste, gracias.

A mi madre y a mi madrina por el sacri�cio y la ayuda que me dieron siempre, gracias.

A Alberto por el sacri�cio que hizo durante 20 años, gracias.

A mis cinco hermanos y a toda la gran familia que tengo, gracias.

Muy especialmente a mi padre que desde algún lugar me está mirando y está orgulloso de su hijo, graciaspor la familia que me diste y por todo.

A todos los compañeros que pasaron meses sin dormir para terminar las entregas, gracias Favio, Dani y José.

A Arturo por su tiempo y dedicación.

A la Universidad de Buenos Aires que me brindó una educación de excelencia de manera gratuita.


3 INTRODUCCIÓN

3. Introducción

La mayoría de los sistemas de software requieren almacenar y recuperar información de dispositivos de alma-cenamiento masivo para cumplir sus objetivos. Determinado tipo de información requiere ser accedida por variosprocesos (aplicaciones que están en ejecución) en paralelo, es decir, se debe poder acceder de manera concurrente.La forma de almacenar la información es mediante archivos; éstos son unidades lógicas de almacenamiento deinformación, y los sistemas de software o aplicaciones son los que deben saber interpretar los datos para transfor-marlos en información.El tamaño mínimo que puede tener un archivo es el tamaño de un bloque, esto se debe a que un bloque es launidad mínima de almacenamiento. Existen dos operaciones que sobresalen del resto en cuanto a importancia,estas son la lectura y la escritura de bloques.Los archivos son administrados por el sistema operativo, y la parte del sistema operativo que trata la adminis-tración de los archivos se conoce como sistema de archivos, que es el tema de la tesis.


4 RELEVAMIENTO BIBLIOGRÁFICO SOBRE SISTEMAS DE ARCHIVOS

4. Relevamiento bibliográ�co sobre sistemas de archivos

4.1. Asignación de bloques a archivos

Los archivos se almacenan en bloques, y el conjunto de bloques asignados a un archivo contiene la totalidad dela información almacenada en él. Para recuperar todo el archivo se debe tener algún mecanismo para referenciara todos estos bloques. A continuación se hace una descripción de distintas opciones.

4.1.1. Asignación contigua

Este es el mecanismo más simple de los utilizados ya que se basa en almacenar el archivo en bloques adyacentes;de esta manera un archivo de 10kb y bloques de 1kb tendría 10 bloques seguidos.En la imagen 4.1 se visualiza un ejemplo de tres archivos y con bloques libres a continuación de los del archivo C.

Este método tiene dos grandes virtudes, la primera es que es de fácil implementación ya que los datos necesariospara la implementación son el número del primer bloque y la cantidad de los mismos.La otra virtud que tiene este método es que la recuperación del archivo completo se puede realizar con elmínimotiempo de seek posible (tiempo de posicionamiento de un bloque para ser leido) ya que los bloquesson contiguos.Por lo tanto este método tiene las ventajas de ser de fácil implementación y además tiene alto rendimiento; pero encontraposición tiene la gran desventaja de que con el paso del tiempo muchos de los archivos creados son borrados,por lo tanto los bloques que ocupaban quedan libres y esto produce lo que se conoce como fragmentación (tambiénse puede dar cuando se actualiza un archivo de manera que cambie su tamaño). Este efecto se puede visualizaren la imagen 4.2.



Con el paso del tiempo esta fragmentación se vuelve problemática porque en algún momento la unidad de alma-cenamiento se puede llenar y entonces se deben reutilizar los bloques que fueron liberados con anterioridad. Paraesto se debe calcular el tamaño del archivo a crear y recorrer todos los huecos hasta encontrar uno tal que sutamaño sea mayor o igual que el de el archivo que se desea almacenar [1].

4.1.2. Asignación por lista enlazada

Esta variante se caracteriza por mantener los bloques de los archivos enlazados mediante referencias de maneraque constituyan una lista. Se utilizan algunos bytes de cada bloque para apuntar al siguiente.Con este método no se pierde espacio por fragmentación (excepto por la fragmentación interna del último bloquede cada archivo); además, para la entrada al directorio sólo se necesita la dirección del primer bloque porque porlas referencias internas se obtiene siempre el siguiente.Una contra que tiene este método es que para llegar al bloque n de un archivo se necesita leer sus n-1 bloquesprevios, lo cual no es para nada e�ciente.En la imagen 4.3 se ejempli�ca una lista enlazada de bloques para un archivo llamado A. [1]

4.1.3. Asignación por lista enlazada utilizando una tabla en memoria

Una manera de eliminar las desventajas del método de lista enlazada es tener los apuntadores de los bloquessiguientes en una tabla externa a los bloques que esté en memoria.En la imagen 4.4 se observa la tabla en cuestión para el archivo A utilizado en el método anterior.



La tabla en cuestión es la llamada FAT (File Allocation Table); para recorrer un archivo basta con seguir lasecuencia de referencias hasta que se termine. Esta técnica tiene las ventajas de utilizar todo el espacio de losbloques para datos y de no tener que acceder a disco para obtener la referencia del siguiente bloque, ya que latabla, aunque persistida en disco, se maneja en memoria; esto hace que el acceso a todos los bloques del archivosea más rápido que en el método anterior.La principal desventaja es que toda la tabla debe estar en memoria todo el tiempo para que funcione, para discosmuy grandes y tamaños de bloques pequeños se necesitan muchas entradas y eso hace que el tamaño crezcademasiado. Por lo tanto esta técnica es ine�ciente en discos muy grandes. [1]

4.1.4. Nodos-i

Este método se caracteriza por tener una estructura llamada i-node (index node) que contiene los atributos y lalista de los bloques del archivo; por lo tanto para acceder a todos los bloques del archivo se debe acceder a sui-node.El i-node sólo debe estar en memoria cuando está abierto el archivo; esta es una gran ventaja sobre el métodode la FAT, que tiene toda la tabla en memoria. El principal problema de este método es que los i-nodes son detamaño �jo, por lo cual se puede direccionar una cantidad determinada de bloques, y a veces esta cantidad debloques puede ser menor que la que tiene el archivo en cuestión. Una manera de solucionar este problema esreservar el último elemento de la lista de direccionamiento para direccionar un bloque que contiene direcciones debloques y no datos.

En la imagen 4.5 se visualiza la estructura de un i-node. [1]



4.2. Administración de espacio libre

Cuando un archivo incrementa su tamaño o se crea, es necesario obtener unidades de almacenamiento libres parainsertar los datos. La administración del espacio libre se puede realizar mediante un mapa de bits o una listaenlazada de unidades de almacenamiento libres.

4.2.1. Administración mediante mapa de bits

Un mapa de bits es una estructura que asigna un bit de estado a cada unidad de almacenamiento (por ejemplobloques), indicando si está libre o no. Una desventaja de este método es que se debe tener la información de todaslas unidades de almacenamiento en la estructura.Una ventaja es que se accede de manera directa y no se debe realizar un recorrido secuencial hasta ubicar elestado de la unidad en cuestión porque basta con su número para acceder al nodo del mapa y veri�car si está libreo no. Al tener un bit por unidad para indicar su estado se reduce mucho el espacio ocupado por la estructura.Un aspecto en contra es que cuando se requiere espacio libre se debe recorrer secuencialmente toda la estructurahasta obtener los bloques que cubran el espacio libre requerido.La imagen 4.6 ejempli�ca este método. [1]



4.2.2. Administración mediante lista enlazada de unidades de almacenamiento libres

Una lista enlazada es una estructura que tiene una referencia al siguiente nodo y al anterior. Cada uno de losnodos de la lista contiene información de una unidad de almacenamiento (por ejemplo un bloque).Al ser una lista de bloques libres, sólo tiene la información de aquellos que están libres, por lo cual, cuando senecesita espacio para un archivo, se recorre la lista hasta obtener el espacio requerido y se quita de la lista losnodos de los bloques obtenidos.La imagen 4.7 ejempli�ca este método. [1]

4.3. Seguridad

Los permisos sobre los archivos o sobre los directorios permiten el acceso a determinados usuarios o a grupos deusuarios, estos permisos se guardan en estructuras que varían dependiendo el sistema de archivos. Estos permisosse re�eren a permisos de lectura, escritura y ejecución del archivo. Sobre un directorio estos permisos re�erenbásicamente a las operaciones de lectura, escritura y ejecución sobre los archivos que contiene. [2]

4.4. Rendimiento del sistema de archivos

El acceso a disco es mucho más lento que el acceso a memoria. Para leer una palabra de memoria de 32bitsse podrían requerir 10 nseg. La lectura de un disco rígido se podría realizar a 100MB/seg, que es cuatro vecesmás lenta que la palabra de 32bits, pero a esto se le debe agregar de 5 a 10 mseg para realizar una búsquedahasta la pista y después esperar a que se coloque el sector deseado bajo el cabezal de lectura. Si se necesitasólo una palabra, el acceso a memoria está en el orden de un millón de veces más rápido que el acceso a disco.



Como resultado de esta diferencia en el tiempo de acceso, muchos sistemas de archivos se han diseñado con variasoptimizaciones para mejorar el rendimiento.

4.4.1. Uso de cache

Un caché es una colección de bloques que pertenecen lógicamente al disco pero que están en memoria paramejorar el rendimiento del sistema de archivos. Para administrar la memoria caché se analizan todos los pedidosde bloques, y si el bloque está en la cache se devuelve, en caso contrario se accede a la unidad de almacenamientopara obtener el bloque, luego se coloca en la caché y se entrega al proceso que lo solicitó.Para poder realizar este proceso se necesita una estructura que permita veri�car si cierto bloque está en la cachéde manera rápida, para esto se utiliza una tabla hash a la cual se accede mediante un código hash que se obtienecon la dirección de dispositivo. Todos los bloques con el mismo valor de hash se encadenan en una lista enlazadade manera que se pueda localizar todos los bloques del dispositivo.A menudo se debe insertar un bloque en una lista que está llena, cuando este ocurre se debe quitar un bloque yguardarlo en la unidad de almacenamiento, para la selección de dicho bloque se utilizan algoritmos como LRU(menos recientemente utilizado), FIFO (cola), etcétera. [1]

4.4.2. Lectura adelantada de bloques

Esta técnica se basa en tratar de colocar bloques en la caché antes de que se necesiten, de esta manera se incre-menta la tasa de aciertos en la caché. Cuando se solicita al sistema de archivos el bloque n de un archivo, ademásse realiza la veri�cación para ver si el bloque n+1 está en la caché; si no está, se carga con el propósito de quecuando sea solicitado esté cargado o al menos esté en curso.Esta técnica funciona para archivos secuenciales, en archivos de acceso aleatorio perjudica el funcionamiento, paraevitar esto se veri�ca el modo de acceso al archivo para determinar si se trata de un acceso secuencial o aleatorio.

Este método funciona bajo el concepto de localización de los datos, que platea que si se necesita un bloqueen muy probable que se necesite el siguiente en el corto plazo. [1]

4.4.3. Reducción del movimiento del brazo del disco

Esta técnica se basa en colocar los bloque que tengan probabilidad de utilizarse en secuencia uno a continuacióndel otro, preferentemente en el mismo cilindro. Cuando se realiza la creación o incremento del tamaño de unarchivo se debe realizar un análisis para ubicar todos los bloques lo más cerca posible. De esta manera se reduceel movimiento del brazo del disco, con lo cual se reducen los tiempos de acceso y la performance crece. [1]

4.5. Implementación de directorios

Para poder utilizar un archivo primero debe ser abierto, para esto el sistema operativo utiliza el nombre delarchivo en cuestión para localizar la entrada del directorio. Esta entrada provee la información necesaria paraencontrar todos los bloques del archivo. Por lo tanto la función principal de un sistema de directorios es realizarla asociación del nombre del archivo y la información necesaria para obtener todos sus datos.Una cuestión muy relacionada es en dónde se guardan los atributos de los archivos. Una opción es guardar estosatributos en el mismo directorio, de esta manera los directorios son una lista de nombres de archivo, atributos ybloques de dicho archivo. Este método se ejempli�ca en la imagen 4.8.



Otra técnica es guardar los atributos en i-nodos, de esta manera el directorio es una lista de nombres de archivomás un número de i-nodo en el que se encuentra la información del archivo como atributos, i-nodo, etc.Este método se ejempli�ca en la imagen 4.9.

Otro tema importante para tratar es la implementación de los nombres de los archivos: algunas implementacionessoportan archivos con 8 caracteres de nombre más 3 de extensión, otras soportan 14 caracteres, sin embargo lossistemas operativos modernos soportan nombres de archivo largos; a continuación se detallan algunas maneras deimplementarlo.Una posible implementación es reservar 255 caracteres para el nombre de cada archivo que exista, el problemacon esto es que se desperdicia mucho espacio debido a que el nombre puede tener menos de 255 caracteres. Otrométodo es tener un encabezado por archivo que contenga determinados datos como por ejemplo la longitud delnombre y a continuación esté el nombre del archivo, de esta manera no se desperdicia espacio. Un problema quetiene este método es que cuando se borra algún archivo queda un hueco de longitud variable.Otra alternativa es tener un encabezado en el directorio en el que se encuentre la referencia al nombre del archivo yatributos; el nombre del archivo se ubica en otro sector del directorio reservado para almacenar todos los nombresde los archivos.En lo que respecta a búsquedas de un archivo dentro de un directorio, se usan tres métodos que se describen acontinuación.El primer método es realizar una búsqueda secuencial hasta encontrar el archivo que se está buscando; esto puedellegar a ser muy costoso en el caso que se tenga muchos archivos en el directorio.Una alternativa al método anterior es tener una tabla hash para cada directorio en la cual la clave es el nombredel archivo, este método es mucho más e�ciente que el anterior pero le gana en complejidad.Una mejora del primer método es tener una caché para los nombres de los archivos: antes de realizar la búsquedase veri�ca en la cache si está el nombre del archivo, y en el caso de que no esté se realiza la búsqueda dentro deldirectorio y al resultado se lo ubica en la cache. [1]

4.6. Nuevas prestaciones en sistemas de archivos

Con el avance de los sistemas de archivos fueron surgiendo nuevos tipos que resuelven los problemas antes plantea-dos y agregan nuevas prestaciones.Algunas de estas nuevas prestaciones son utilizar la cache de disco de una manera más efectiva, garantizarla integridad (recuperación de fallos) y proveer una interfaz virtual para trabajar con distintas implementa-ciones de sistemas de archivos.



4.6.1. Sistemas de archivos estructurados por registro

El tipo de sistemas de archivos estructurado por registro nació como consecuencia del incremento de la velocidadde las CPU, del incremento en el tamaño de las memorias RAM y del incremento en en el tamaño de las cachede disco. En consecuencia es posible satisfacer gran parte de las lecturas a disco desde la cache sin tener queacceder al disco.La idea es estructurar todo el disco como un registro. Todas las escrituras a disco son colocadas en un bu�eren memoria, y periodicamente todas las pendientes se escriben en el disco (al �nal del registro) como si fuera unsolo segmento. Para que este mecanismo funcione cada segmento debe tener toda la información administrativanecesaria de las estructuras que contiene ya que puede contener i-nodos (en el caso de unix), bloques dedirectorios, bloques de archivos, etc.[1]Este método se ejempli�ca en la imagen 4.10.

Este tipo de sistemas de archivos tiene un mecanismo para liberar el espacio que ya no se utiliza, por ejemploel espacio que estaba asignado a un archivo que fue borrado. Periodicamente se recorre el registro de maneracíclica comenzando por el primer segmento y analizando la información que contiene para liberar los bloquesque ya no son utilizados.

4.6.2. Sistemas de archivos por bitácora

La idea de este sistema de archivos es mantener un registro de lo que se va a hacer antes de hacerlo, por lo tantosi el sistema falla antes de realizar alguna tarea, cuando se reinicia el sistema puede buscar en el registro lo quese iba a realizar y completar dicha tarea.

Para que un sistema de archivos por bitácora funcione las operaciones que realiza deben ser idempotentes, locual signi�ca que puede repetirse todas las veces que sea necesario sin peligro alguno.

Además, para ofrecer mayor seguridad se puede utilizar el concepto de base de datos llamado transacciones, deesta manera el sistema de archivos agrupa operaciones a realizar y sabe que deben ejecutarse sin problema todaso ninguna. [1]

4.6.3. Sistemas de archivos virtuales

A menudo en una computadora hay más de un sistema de archivos instalado, los sistemas operativos controlaneste aspecto de determinadas maneras, lo que se busca con un sistema de archivos virtual (VFS) es integrardiferentes sistemas de archivos en una unidad ordenada. La idea principal (y clave) es poner todo lo que es com-partido por todos los sistemas de archivos en una capa separada que llame a los sistemas de archivos concretossubyacentes para administrar los datos.

Todas las llamadas al sistema relacionadas con archivos se dirigen al sistema de archivos virtual para su proce-samiento inicial. Estas llamadas, que provienen de procesos de usuarios, son las llamadas estándar como open,



read, write, lseek, etcétera. Por lo tanto, el VFS tiene una interfaz superior para los procesos de usuarios y es lainterfaz llamada POSIX.

El VFS también tiene una interfaz inferior para los sistemas de archivos concretos, esta interfaz consiste dellamadas a funciones que el VFS puede hacer a cada sistema de archivos para realizar su trabajo. Por lo tantopara que un sistema de archivos trabaje con el VFS basta con que suministre las llamadas a las funciones querealiza el VFS.

En la imagen 4.11 se ejempli�ca este sistema de archivos. [1]

4.7. Casos de estudio de sistemas de archivos

Cada sistema de archivos utiliza diferentes técnicas para los aspectos antes descriptos, en esta sección se ejempli-�carán varios sistemas de archivos describiendo sus principales estructuras para la administración de los archivosasí como los métodos utilizados por cada uno.

4.7.1. DOS (Disk Operating System)

Las unidades de almacenamiento son los llamados �clusters�, estos son conjuntos de sectores del disco (cada sectortiene 512 bytes) que dependiendo de determinados parámetros (como el tamaño del disco) pueden ser: dos, cuatro,ocho, etcétera sectores por clusters (siempre potencia de dos).Los directorios son de longitud variable, pero tienen entradas o registros de longitud �ja de 32 bytes que contienelos datos del archivo al que referencia, la estructura de estos registros se observa en la imagen 4.12



Como se puede apreciar el nombre de los archivos puede tener hasta ocho caracteres y tres de extensión, estainformación se almacena en los ocho primeros bytes de cada registro.

El byte destinado a los atributos especí�ca si es un archivo de sistema, de sólo lectura, si está oculto, si esun subdirectorio, etcétera.

Los bytes 21 al 25 contienen la fecha y hora de creación o de última Modi�cación del archivo, la hora se di-vide en segundos (5 bits), minutos (6 bits) y horas (5 bits). La fecha se cuenta en días usando tres subcampos:día (5 bits), mes (4 bits) y año desde 1980 (7 bits).

El número del primer bloque del archivo se encuentra en el byte 25 y tiene una longitud de dos bytes.

Además se almacena el tamaño del archivo en los últimos cuatro bytes del registro, por lo tanto en teoría unarchivo podría ocupar hasta 4 GBytes, aunque por motivos que se analizarán a continuación el tamaño máximode un archivo es de 2 GBytes o menos.

La cuenta de los clusters se lleva a través de una tabla de asignación de archivos (FAT) en la memoria prin-cipal. Dado que cada registro de directorio tiene el número del primer cluster del archivo se puede acceder a latabla y navegarla para obtener todos los clusters del archivo. En la imagen 4.4 se observa la tabla en cuestión.

La tabla en cuestión puede ser FAT-12, FAT-16 o FAT-32, dependiendo de la cantidad de bits que tengacada dirección de disco.

FAT-12 proporciona un tamaño máximo de partición igual a 4096 x 512 Bytes (en realidad 4086 x 512 Bytes de-bido a que 10 de las direcciones del disco se utilizan para otras cuestiones como �n de archivo, cluster defectuoso,etc.) que da aproximadamente un tamaño máximo por partición de 2 MB, el tamaño de la FAT en memoria esde 4096 entradas con 2 Bytes cada una.

FAT-16 tiene 16 bits para direccionar lo cual incrementa el tamaño máximo por partición a un máximo de2 GBytes, la tabla FAT ocupa un total de 128 KBytes de memoria principal todo el tiempo.

FAT-32 tiene 28 bits para direccionar clusters, el tamaño máximo por partición está acotado a 2 TBytes debidoa que el sistema lleva de manera interna la cuenta de los tamaños de las particiones utilizando un número de32 bits. Dado que un archivo requiere como mínimo un cluster para su almacenamiento una gran ventaja deFAT-32 es que se desperdicia poco espacio en comparación a las demás FAT, esto se debe a que permite tamañode clusters más pequeños que las demás FAT, por lo tanto al almacenar un archivo que ocupe menos espacio queun cluster se desperdicia el espacio que le queda libre al cluster que es menos que en la demás FAT.

DOS utiliza la FAT para llevar la cuenta de los clusters libres en el disco. Cualquier cluster que esté librese marca con un código especial, y cuando se necesita un cluster libre se lo busca en la FAT. De esta manera seevita la utilización de un mapa de bits o de una lista enlazada para clusters libres. [1] [2]



4.7.2. NTFS (New Technology File System)

Estructura del sistema de archivos:

Cada partición de disco (volumen) de NTFS contiene archivos, directorios, mapa de bits y otras estructurasde datos. Cada partición se organiza en una secuencia de clusters, el tamaño de estos está �jo y varía de acuerdoal tamaño de la partición.

Para hacer referencias a los clusters se utiliza su o�set desde el inicio de la partición mediante un número de64 bits.

La estructura principal es la llamada MFT(Tabla maestra de archivos), esta es una secuencia de registros deun 1KB de tamaño, donde cada registro describe un archivo o directorio, es decir, contiene los atributos como sunombre, una lista de direcciones en el disco en donde se encuentran sus clusters, etc. En el caso de que un archivosea muy grande se usa más de un registro para direccionar a todos los clusters de dicho archivo, con lo cual elprimer registro de la MFT llamado �registro base� direcciona a los otros registros. Un mapa de bits controla lasentradas libres de la MFT. La imagen 4.13 describe la estructura de la MFT.

Cada registro de la MFT consiste en una secuencia de pares (encabezado de atributo-valor). Cada atributo comien-za con un encabezado que indica qué tipo de atributo es, y cuál es el largo del valor. Algunos valores de atributosson de longitud variable como es el nombre del archivo y los datos. Si el valor del atributo es lo su�cientementecorto como para caber en el registro se deja allí, en caso contrario se almacena en algún lugar de la unidad dealmacenamiento y se almacena su ubicación en el valor del par atributo-valor en cuestión.



Los primeros 16 registros de la MFT se reservan para archivos de metadatos como se observa en la imagen4.13. El primer registro está destinado a la ubicación de los clusters de la MFT; pero es necesario conocer laubicación del primer cluster de la MFT para poder acceder a ella y así conocer la ubicación de los demás, paraesto se debe acceder al bloque de inicio de la partición (volumen) que entre otros datos contiene la dirección delcluster en cuestión.

NTFS de�ne 13 atributos que pueden aparecer en los registros de la MFT, esto se muestran en la imagen 4.14.

El campo información estándar contiene la información del propietario, información de seguridad, lacantidad de enlaces duros, los bits de sólo lectura, etc. Es un campo de longitud �ja.

El campo nombre de archivo contiene el nombre del archivo en unicode y es de longitud variable.

El campo descriptor de seguridad sólo se utiliza en NT 4.0 ya que en los siguientes sistemas operativosse colocó en un archivo, por lo tanto para ellos este campo está obsoleto.

El campo lista de atributos se utiliza en el caso de que de que los atributos no quepan en la MFT e indicaen dónde ubicar los registros de extensión.

El campo ID de objeto se utiliza para acceder a los archivos.

El campo punto de reanálisis indica en nombre del procedimiento que se utiliza para montar sistemas dearchivos de manera explícita y para los vínculos simbólicos.

Los campos de volumen se utilizan para identi�car el volumen.

Los campos raíz de índice, asignación de índice y mapa de bits se relacionan con la manera en quese implementan los directorios, los pequeños son listas de archivos, y los grandes son árboles B+.

El campo �ujo de utilería con registro es usado por el sistema de archivos de cifrado.

El campo datos representa los datos del archivo, en el caso que los datos sean pocos se ubican en esteatributo (archivo inmediato), en caso contrario representa las direcciones de los clusters del archivo. [1]



Asignación de los clusters para el almacenamiento:

Por cuestiones de e�ciencia los clusters de un archivo se almacenan de manera contigua siempre que sea posible.Cada conjunto de clusters contiguos de un archivo se describe mediante un registro. Esto será analizado en detalleen la sección de relevamiento bibliográ�co y tendencias tecnológicas.

Compresión de archivos:

NTFS proporciona compresión para los archivos, se pueden crear archivos en modo comprimido, por lo tantoNTFS trata de comprimirlos a medida que se escriben sus datos en el disco y los descomprime cuando se leen. Lacompresión se basa en aplicarle un algoritmo de compresión a los primeros 16 clusters del archivo y si consiguecomprimirlos se guardan de manera comprimida, en el caso de que no se puedan comprimir los datos se guardansin comprimir. Lo mismo se hace para las siguientes secuencias de clusters, siempre tomando de a 16 salvo en laúltima secuencia que pueden ser menos. La compresión se aplica más allá de si los clusters se ubican en secuenciaconsecutiva o no.

En la imagen 4.15 se muestra un archivo en el que los primeros 16 clusters se comprimieron con éxito en 8,los 16 clusters siguientes no se pudieron comprimir, y los siguientes 16 se comprimieron un 50%. Las tres partesse han escrito como tres secuencias de clusters consecutivos y se han almacenado en el registro de la MFT. Losclusters faltantes se han almacenado en la MFT con la dirección de disco 0, como se muestra en la imagen (b).Aquí el encabezado (0, 48) va seguido de cinco pares, dos para el primer conjunto de clusters consecutivos (com-primido), uno para el conjunto descomprimido y dos para el conjunto �nal (comprimido).



Cuando el archivo se vuelve a leer, NTFS debe saber cuáles con los conjuntos de clusters que están comprimidosy cuáles no, para esto se analiza la dirección de disco inicial de cada uno que está en su par (dirección inicial �cantidad de clusters) correspondiente, si la dirección inicial es 0 indica que es parte �nal de 16 clusters comprim-idos, esto se puede observar en la imagen 4.15 (b). Esto se basa es que el cluster cero de la partición no se puedeutilizar para almacenar datos. [1]

Registro de transacciones:

NTFS proporciona dos mecanismos de registro de transacciones, el primero se basa en una operación de E/Sllamada NtNotifyChangeDirectoryFile, que se basa en una llamada CallBack que recibe un bu�er del sistema,este bu�er se llena con datos de cambios en directorios y archivos, es decir, con el registro de los cambios de lapartición.

El otro mecanismo se basa en persistir todos los cambios de la partición en un archivo que puede ser consultadomediante llamadas a la API de NtfsControlFile, esta función es la llamada FSCTL_QUERY_USN_JOURNAL.[1]

4.7.3. UNIX

En Unix, el sistema de archivos es uno de los componentes del kernel. Los procesos interactúan con el sistema dearchivos a través de las system calls que a su vez pueden hacer llamadas a funciones de más bajo nivel del sistemade archivos.

El sistema de archivos interactúa con los dispositivos a través de los drivers especí�cos de cada uno. En elcaso de que los dispositivos son orientados a bloques, existe un nivel de bu�ering entre el sistema de archivos ylos dispositivos. Esto se puede observar en la imagen 4.16.

Cabe mencionar que la unidad mínima de almacenamiento en UNIX se denomina bloque y no un cluster comoen NTFS. [2]

I-Nodos:



La estructura principal para la administración de los archivos es el i-nodo, esta estructura es de tamaño �joy contiene la siguiente información:

Identi�cación del creador del archivo.

Tipo de archivo, esto es por ejemplo, normal, directorio, etc. Este campo suele utilizarse además paraindicar si el i-node está libre.

Permisos de acceso, cada archivo admite tres tipos de permisos, lectura, escritura y ejecución. Cada uno deestos permisos puede ser negado de manera independiente al dueño del archivo, a su grupo y al resto de losusuarios.

Fecha de la última modi�cación del archivo, último acceso al mismo, última fecha de modi�cación del i-nodo,etc.

Número de links al archivo, el i-nodo de cada archivo es único, sin embargo, el archivo puede ser referenciadodesde diferentes directorios bajo distintos nombres, estas referencias se denominan links.

Tamaño del archivo.

Tabla de asignación de DataBlocks, un archivo puede estar almacenado en bloques contiguos o no; estatabla contiene la dirección de los bloques que forman los archivos, cada uno de estos bloques se denominaDataBlock. Dado que los i-nodos son de tamaño �jo y que la cantidad de bloques del archivo correspondi-ente al i-nodo puede ser muy grande, se necesita un mecanismo para referenciar las direcciones de bloquesque no se puedan almacenar en el i-nodo, este mecanismo es el llamado �mecanismo de indirección� ,esto es, las primeras entradas corresponden a direcciones de bloques mientras que las siguientes referenciana bloques que contienen direcciones de bloques. Los niveles de indirección pueden ser varios. La imagen4.17 representa un esquema de indirección de tres niveles. [2]



Tablas del Kernel:

Los i-nodos se almacenan en los mismos dispositivos de almacenamiento en los que reside el contenido de losarchivos, sin embargo el sistema de archivos mantiene algunas tablas en memoria para agilizar y coordinar acce-sos a los archivos, estas son las siguientes:

Tabla de i-nodos: Es una tabla global del kernel que por cada entrada contiene los datos del i-nodo corre-spondiente, además de la siguiente información:

1. Referencia al sistema de archivos en el que se encuentra el archivo.

2. Contador de procesos que están utilizando el archivo asociado al i-nodo en cuestión.

3. Número de i-nodo dentro de la lista de i-nodos del sistema de archivos.

4. Estado, este puede ser de lockeo, de proceso en espera (indica si al menos un proceso se encuentra enespera para acceder al archivo asociado al i-nodo), indica además si el i-nodo se modi�có en memoriapero no se persistió en el medio de almacenamiento, etcétera.

Tabla de archivos: Es una tabla global del kernel a la que se le agrega una entrada cada vez que se abre ocrea un archivo. Esta entrada contiene un puntero al i-nodo correspondiente de la tabla de i-nodos, ademásy mantiene información adicional como la posición de lectura o escritura dentro del archivo (o�set), lospermisos con los que el proceso accede al archivo, la cuenta del número de descriptores de archivos abiertos,etc.

Tabla de descriptores de archivos de usuarios: Es una tabla a la que se le agrega una entrada cada vez queun proceso abre o crea un archivo. La diferencia con las dos tablas anteriores es que no es una tabla global,sino que se tiene una tabla para cada proceso. Cada entrada de esta tabla contiene un puntero a la tabla dearchivos e información adicional como el �le descriptor con el que el proceso accederá al archivo. Si unproceso abre dos veces el mismo archivo recibirá dos �le descriptor diferentes, cada uno estará asociadoa una entrada diferente en la tabla en cuestión y cada una de estas entradas tendrá un puntero diferente ala tabla de archivos; esta es la manera mediante la cual el kernel mantiene dos o�sets diferentes al mismoarchivo para el mismo proceso. Existen calls que permite evitar este comportamiento. [2]

Directorios:

Un directorio es un archivo cuyo contenido es una secuencia de registros de longitud variable que contienenla longitud del registro, un número de i-nodo, la longitud y la secuencia de caracteres que representan el nombredel archivo (asociado al i-nodo) con el que se ve dentro del directorio en cuestión.

La escritura en los directorios se reserva al kernel, es decir, todas las escrituras sobre estos archivos se real-izan mediante las system calls correspondientes, esto permite garantizar la integridad del sistema de archivos.Los campos de permisos de los directorios tienen un signi�cado diferente al de los archivos que no son directorios,ya que se tratan de permisos para crear archivos dentro de él, buscar archivos, leer, etcétera. La imagen 4.18esquematiza un directorio. [2]



Bu�ering:

Como se mencionó anteriormente, los drivers de los dispositivos orientados a bloques se comunican con el sistemade archivos mediante una técnica de bu�ering. La cantidad de bu�er que el kernel administra es un parámetro delsistema operativo, y el control de los mismos se implementa mediante colas de dispersión doblemente enlazadasa las que se accede a través de registros de cabecera.

Los nodos de la cola de bloques, además de estar enlazadas para conformar una cola de dispersión, tienen enlacespara conformar una cola de enlaces libres.

Cada nodo de la cola de dispersión está formado por los siguientes datos:

1. Número de dispositivo.

2. Número de bloque.

3. Puntero a área de datos.

4. Puntero al próximo registro de la cola de dispersión.

5. Puntero al anterior registro de la cola de dispersión.

6. Puntero al próximo bu�er libre.

7. Puntero al anterior bu�er libre.

8. Estado, este valor puede ser, bloqueado, datos válidos, se debe escribir antes de reasignarlo, se está leyendoo escribiendo actualmente, un proceso está esperando que se libere el bu�er.

Para buscar un bloque en la cola de dispersión se aplica una función de hash a la que se le pasa como parámetrosel número de dispositivo y el número de bloque, en el caso de que el bloque buscado no se encuentre en la cola selee desde el disco y se carga en la cola. [2]

4.7.4. EXT-2

Este sistema de archivos se creó para reemplazar a su predecesor llamado ext, este tenía varios problemas en elrendimiento. La imagen 4.19 nuestra una partición con ext-2.



El bloque 0 contiene información para el inicio de la computadora, luego de este la partición se divide en conjuntosde bloques.

El súper bloque contiene información sobre la distribución del sistema de archivos, incluyendo el número dei-nodos, el número de bloques de disco y el inicio de la lista de bloques libres.

El descriptor de grupo contiene información de la ubicación de los mapas de bits, el número de bloqueslibres, número de directorios y número de i-nodos en el conjunto de bloques.

Los dos mapas de bits representan los bloques libres y los utilizados. Estos mapas son de tamaño �jo, porlo tanto la cantidad de bloques que pueden mapear está limitada.

Por último están los i-nodos y luego los bloques de datos, aquí se almacenan todos los datos de los archivosy directorios, puede ocurrir que si un archivo es lo su�cientemente extenso, los bloques que lo forman no seancontiguos, sino que pueden estar esparcidos por todo el disco.

Cuando se crea un archivo, se le asignan ocho bloques adicionales para minimizar la potencial futura frag-mentación debido a las futuras operaciones de escritura.

Los nombres de los archivos pueden tener hasta un largo de 255 caracteres.

La imagen 4.20 describe la estructura de un directorio.

Las búsquedas de archivos en los directorios son secuenciales. En un directorio con muchos archivos esta operaciónpuede ser extremadamente lenta, por lo tanto para evitar este problema se utiliza una cache de los directorios deacceso reciente. Para buscar en esta cache se utiliza el nombre del archivo, y de encontrarse el archivo se evita lalectura secuencial. [1]



4.7.5. EXT-3

Este sistema de archivos es el sucesor de ext-2, y se caracteriza por tener una implementación de transacciones.Cada modi�cación en el sistema de archivos se graba en un archivo secuencial, de esta manera si se produce unafalla en el sistema, al iniciar nuevamente se leerá el archivo de transacciones y se efectuarán los cambios que nopudieron ser efectuados.

Las operaciones de lectura y escritura sobre el archivo de transacciones no son realizadas por el sistema dearchivos, sino que las realiza un dispositivo de bloque transaccional (JBD).El JBD proporciona tres estruc-turas de datos principales, el registro diario, el manejador de operaciones atómicas y la transacción. Unregistro diario describe una operación de bajo nivel del sistema de archivos, que por lo general son cambios dentrode bloques. El sistema de archivos noti�ca al JBD sobre el inicio y el �n de una llamada al sistema para que estepueda asegurar que se apliquen todos los registros diarios en una operación atómica, o que no se aplique ninguno.El JDB elimina los registros diarios una vez que se veri�ca que se aplicaron los cambios que ellos representan, deesta manera se evita tener operaciones en el archivo de transacciones que ya fueron aplicadas. [1]

4.7.6. EXT-4

Este sistema de archivos es el sucesor de ext-3 y tiene varias mejoras con respecto a éste que se enumeran acontinuación.

1. Es capaz de trabajar con volúmenes de hasta 1EByte y el tamaño máximo de archivos es 16TByte.

2. El concepto de bloques utilizado en unix se reemplaza por extents, estos son grupos de bloques contiguosque permiten mejorar el uso de archivos de gran tamaño y se reduce la fragmentación.

3. Se implementó una nueva llamada al sistema (preallocate()) que se agregó al kernel de Linux, esta op-eración realiza la reservación de espacio para un archivo siendo muy probable que sea contiguo.

4. Se implementó una técnica que mejora el rendimiento llamada Allocate-on-�ush, esta consiste en retrasarla reserva de bloques en memoria hasta que la información esté a punto de ser persistida en la unidad dealmacenamiento. Esta técnica mejora el rendimiento y reduce la fragmentación al mejorar las decisiones dereserva de memoria basada en el tamaño del archivo.

5. Se superó el límite de profundidad de subdirectorios que era de 3200, es incrementó a 64000.

6. Los timestamps soportan nanosegundos. [6] [7] [9]

4.7.7. HFS (Hierarquical File System):

Este sistema de archivos no maneja los archivos como streams solamente, sino que están formados por dos partes,una sección llamada Data fork y otra llamada resource fork. La sección data fork contiene los datos creadospor el usuario, en cambio la sección resource fork contiene una cabecera de los recursos, los recursos propios y unmapa de los recursos. Entiéndase por recursos a íconos, menues, controles de la aplicación. [2] [3] [4]

Un problema que tenía el sistema de archivos predecesor a este, es que al momento de buscar todos los archivosdentro de un directorio debía acceder a un archivo en el que se almacenaba esta información, esta operación paradirectorios con muchos archivos era lenta, por lo tanto la solución implementada fue crear el llamado catalog �le(es un árbol B*) para realizar las búsquedas con mayor rapidez. Para realizar las búsquedas utiliza un módulollamado �nder que se encarga de consultar el árbol B* para obtener los resultados.

En la imagen 4.21 se muestra la estructura de un volumen de HFS.



Las principales estructuras de este sistema de archivos se analizan a continuación:

1. El sector de arranque del volumen contiene información para el inicio del sistema, por ejemplo el nombredel archivo de shell y del �nder que se cargan al iniciar.

2. El directorio MDB (Master directory block) , tiene la información de la partición y dónde localizar las demásestructuras.

3. Mapa de bits de bloques para determinar los que están libres y los que no.

4. El catalog �le que es un árbol B* que contiene información para todos los archivos y directorios almacenadosen el volumen. Cada archivo consiste en un �le thead record y un �le record, mientras que cada directorioconsiste en un directory thead record y un directory record.

Un �le thread record almacena sólo el nombre del archivo y el CNID (catalog node id) de su directoriopadre.

Un �le record almacena varios metadatos como son el CNID y tamaño del archivo, tres timestamps(creación, modi�cación y cuándo se realizó la última copia de seguridad), datos referidos a los recursos,y un puntero al primer bloque de datos del archivo. También, almacena dos campos de 16 bytes queson usados por el �nder para acelerar las búsquedas de archivos.

Un directory thread record almacena sólo el nombre del directorio y el CNID del directorio padre.

Un directory record almacena datos como el número de �cheros almacenados en el directorio, el CNIDdel directorio, tres timestamps (creación, modi�cación y último backup), almacena dos campos de 16bytes para uso del �nder.

5. El archivo de desbordamiento que se utiliza en el caso de que algún archivo tenga su sector data forkdesbordado, en este caso los datos que no quepan en dicho sector se almacenan aquí, es un árblo B*.

6. Una copia del MDB para utilizar en el caso de que se corrompa el original.

Este sistema de archivos tiene los siguientes problemas:

1. Dado que el direccionamiento es de 16 bits si el volumen es grande los bloques tendrán demasiado tamañoy se desperdiciará demasiado espacio cuando un archivo no ocupe al 100% todos sus bloques.

2. Cada vez que se modi�ca un archivo o directorio se accede al catalog �le, dado que más de un procesono puede modi�car esta estructura al mismo tiempo los procesos quedan en cola esperando su turno, estoreduce la performance.

3. Si el catalog �le se corrompe se pierde todo el sistema de archivos dado que no se tiene una copia del catalog�le y que toda la información de los archivos y directorios está en éste y no distribuida.

4. Para direccionar bloques se utiliza un número de 16 bits, por lo tanto la cantidad de bloque para un archivose limita a 65536. [2] [3]



4.7.8. HFS+ (HFS plus)

Este sistema de archivos se creó para reemplazar a HFS, tiene varias mejoras comparadas con el anterior que seenumeran a continuación:

1. El mapa de bits fue reemplazado por un archivo, de esta manera se puede incrementar si la partición crece,este nuevo archivo es llamado allocation �le.

2. El direccionamiento a los bloques se realiza mediante un número de 32 bits, con esto se termina la limitaciónde 65536 bloques máximos para un archivo.

3. Los registros del catalog �le (B*) son de mayor tamaño.

4. Los bloques dañamos se ubican en el archivo de desborde.

5. Se implementó un nuevo archivo (B*) llamado atributes �le para direccionar atributos, este archivo esutilizado por el �nder para mejoras la velocidad de respuesta de las búsquedas.

6. El MDB fue reemplazado por un header que contiene información sobre el volumen.

7. Se implementó un nuevo archivo de inicio, llamado startup �le, que es utilizado para sistemas de archivosque no son HFS o HFS+ puedan utilizar la interfase de acceso a los archivos.

8. El nombre de los archivos soporta caracteres Unicode. [2] [5]

4.7.9. HPFS

Este sistema de archivos fue creado especi�camente para el sistema operativo OS/2 mejorando algunas de laslimitaciones de FAT.

Algunas de las características se mencionan a continuación:

1. La ordenación de los directorios se basa en el nombre de los archivos.

2. Utiliza una estructura más e�ciente para organizar los directorios, de esta manera, se utiliza menos espacioen el almacenamiento y el acceso a los archivos es más rápido con respecto a FAT.

3. Los archivos se ubican en sectores en vez de clusters.

4. Para la administración del espacio libre se utilizan mapas de bits.

5. Los nombres de los archivos pueden ser de hasta 255 caracteres.

6. Los nombres de los archivos soportan unicode.

7. Si un sector está defectuoso, se marca como tal y la información contenida en él se mueve a otro. [2]

4.7.10. ZFS

Este sistema de archivos se destaca por tener una gran capacidad, integración de conceptos (anteriormente sep-arados) como sistema de archivos y administrador de volúmenes, sencilla administración del espacio de almace-namiento.

Algunas de las características se mencionan a continuación:

1. Los punteros a bloques contienen un checksum de 255 bits sobre el bloque apuntado que se comprueba cadavez que se lee el bloque en cuestión. Los bloques que contienen información activa no se sobrescriben nunca,en su lugar se reserva un nuevo bloque y los datos modi�cados se escriben en él, por lo tanto cualquierbloque de metadatos que lo referencie es reubicado y escrito de manera similar. Para reducir la sobrecargaque genera este proceso, se agregan varias actualizaciones en grupo de transacciones, y se utiliza un log deintentos cuando se necesitan escrituras sincrónicas.

2. Utiliza bloque de tamaño variable hasta 128KB, además soporta compresión de bloques, en el caso deactivarse la compresión se disminuye el uso de espacio, pero se incrementa el trabajo de procesador.



3. A medida que se agregan dispositivos, el ancho de banda se expande de forma automática para incluirlos, demanera que se utilizan todos los discos en el pool para balancear la carga de escrituras entre los dispositivos.

4. A diferencia de los sistemas de archivos tradicionales que residen sobre de un solo dispositivo, ZFS utilizaespacios de almacenamiento virtuales. Estos se construyen a partir de uno o más dispositivos virtuales, deesta manera el sistema de archivos puede estar montado en un dispositivo que tenga menor capacidad dealmacenamiento del que se necesita y utilizar otros para compensar la falta de espacio. [8]


5 RELEVAMIENTO BIBLIOGRÁFICO DE MÉTODOS Y TENDENCIAS PARA OPTIMIZAR ELRENDIMIENTO DE SISTEMAS DE ARCHIVO

5. Relevamiento bibliográ�co de métodos y tendencias para optimizarel rendimiento de sistemas de archivo

En esta etapa se analizarán las líneas de investigación sobre las siguientes problemáticas en los sistemas dearchivo, pérdida de performance en el tiempo de accedo debido al no cumplimiento del principio delocalidad, y aplicación de bu�er-cache para la optimización de tiempos de acceso.

5.1. Fragmentación en sistemas de archivos y Principio de localidad

5.1.1. Fragmentación de archivos

Al crear, copiar o mover un archivo en la unidad de almacenamiento, el sistema operativo busca bloques de espaciolibre en disco contiguo, donde puede escribir el archivo. Cuando el sistema ope rativo no puede encontrar su�cienteespacio contiguo, busca el espacio libre no contiguo necesario en la unidad de almacenamiento. Como resultado,los bloques del archivo pueden quedar dispersos en lugar de un área contigua de la unidad de almacenamiento.Cuando los bloques de un archivo quedan dispersos se conoce como un archivo fragmentado.Acceder a un archivo implica que se localicen los n bloques que lo forman para obtener toda su información,para realizar el acceso a un bloque primero debe ser ubicado debajo de la unidad de lectura (tiempo de seek), siel archivo está fragmentado este tiempo será mayor que el tiempo de accesso de un archivo no fragmentado.[16]En la imagen 5.1 se visualiza la distribución de los bloques que forman un archivo.

5.1.2. Principio de localidad

El principio de localidad plantea el siguiente escenario, dado un archivo A formado por n bloques, es con-veniente tenerlos ubicados de manera que el tiempo de seek sea el mínimo posible. La fragmentación en losarchivos genera que los bloques de los mismos no cumplan con el principio de localidad.



Para representar esta problemática se plantea el siguiente escenario, en el tiempo t1 se crea el archivo A for-mado por 10 bloques ubicados de manera contigua. En el tiempo t2 se borran 5 bloques del archivoA.En la imagen 5.2 se plantea cómo queda formado en archivo A en el tiempo t2.

En el tiempo t3 se crea el archivo B formado por 4 bloques, estos se insertan en los bloques libres antesfueron ocupados por los bloques del archivo A.En la imagen 5.3 se muestra la distribución de los bloques en el tiempo t3.

En la situación planteada se deduce de qué manera se pierde el principio de localidad con el transcurso deltiempo, a causa de este motivo se ve incrementado el tiempo de lectura del archivo A. El escencario planteado esextremadamente básico, pero en un sistema de archivos real el efecto causado por la maniplación de sus archivos esque el principio de localidad deje de cumplirse para muchos de estos y la performance se vea decrementada,estudios como los que se plantean en [13] indican este fenómeno.

5.2. Desfragmentación y técnicas para reducir la fragmentación en sistemas de

archivos actuales

La desfragmentación en sistemas de archivos es el proceso en el cual se realizan tareas de reubicación de losbloques de los archivos de manera tal que queden en una zona contigua de la unidad de almacenamiento, el �n



de esto es que se cumpla con el principio de localidad.A continuación se analizan los procesos de desfragmentación en varios de los sistemas de archivos actuales.

5.2.1. Sistemas de archivos Windows

Familia de sistemas de archivos FAT

El proceso de desfragmentación en los sistemas de archivos FAT se basa en la reubicación de los bloques delos archivos fragmentados.Los pasos son los siguientes:[10]

1. Análisis del espacio libre en la unidad de almacenamiento.En el proceso de desfragmentación se realizan copias temporales (una por archivo fragmentado), por estemotivo es necesario disponer de espacio en la unidad de almacenamiento para realizar las copias necesarias.Estos nuevos archivos tienen los bloques ubicados de manera que cumplan el principio de localidad lo másque sea posible.

2. Detección de los archivos fragmentados.Esta etapa del proceso se encarga de buscar todos los archivos fragmentados, para este �n se calculasu nivel de fragmentación (cantidad de bloques no contiguos) y se compara con un valor determinado paradecidir si se desfragmenta o no. En este análisis se evitan los archivos que son utilizados por el sistemaoperativo para su con�guración y correcto funcionamiento, archivos defectuosos.

3. Copia de los bloques de los archivos encontrados en el paso 2.A través de la FAT se obtienen las direcciones de los bloques que forman los archivo detectados en el paso2, luego se copian de manera contigua en un sector de la unidad de almacenamiento con el espacio necesariopara ello.

4. Comparación de los archivos originales con los nuevos.Esta etapa se encarga de corroborar que los archivos originales y las copias generadas sean idénticas paraevitar pérdidas de información o inconsistencias.

5. Reemplazo en la FAT de los números de bloques.Las referencias a los bloques que forman los archivos desfragmentados son modi�cadas por las referenciasde las copias generadas.

6. Borrado de los bloques originales.En esta etapa se eliminan los archivos originales, esto se debe a que ya no son utilizados porque fueronreemplazados por los que se generaron en el paso 3.

Familia de sistemas de archivos NTFS

En el caso de los sistemas de archivo NTFS, los pasos son los mismos que los de la familia FAT, las diferenciasse dan en los pasos 2 y 5. Esto se debe a que NTFS no utiliza una tabla FAT, sino que utiliza una tabla llamadaMFT. En esta tabla se almacenan las referencias a los clusters que forman los archivos, por lo tanto es de aquíde donde se toman las referencias para el paso 2, y es donde se modi�can las referencias de los clusters de losarchivos originales.

Los sistemas operativos windows se basan en que el usuario decida ejecutar el proceso de desfragmentación. Desdela versión de Windows Vista existe un proceso que se ejecuta background y realiza tareas de desfragmentación.[10]

5.2.2. Sistemas de archivos archivos Unix

Los sistemas de archivos Unix, para reducir la fragmentación, implementan una técnica llamada �agrupaciónpor cilindros� . Esta técnica se basa en dividir el espacio físico de la unidad de almacenamiento en cilindros.La condición que se aplica sobre los archivos es que sus bloques estén en el mismo cilindro, y en caso de que noquepan en uno, se ubican en cilindros cercanos.Con esta técnica se logra mejorar el principio de localidad y disminuir la fragmentación ya que la separación de



los bloques está limitada a los cilindros o a cilindros cercanos.[12]Está técnica es utilizada en sistemas de archivos como EXT-2, EXT-3 y EXT-4.Existen herramientas como e2defrag (se utiliza en EXT-2) que realizan la desfragmentación y que deben serejecutadas por el usuario.La desfragmentación en sistemas de Unix se basa en la reubicación de los bloques que forman los archivos hacia unmismo cilindro o a cilindros cercanos; además de deben actualizar las i-nodos de los archivos para que direccionenlas nuevas ubicaciones de los bloques.

5.2.3. Sistema de archivos EXT-3

Para este sistema de archivos existen herramientas para la desfragmentación como Shake yDefrag. Shake trabajareservando espacio para todo el archivo de manera que sus bloques queden ubicados en sectores contiguos, paraesto se busca el espacio necesario en toda la unidad de almacenamiento. Defrag copia los bloques de los archivosde manera contigua comenzando en la ubicación física del primer bloque del archivo. Para esto necesita que launidad de almacenamiento tenga mucho espacio libre para hacer copias temporales del contenido de los bloquesque se reemplazan.Una técnica utilizada por este sistema de archivos para reducir la fragmentación es la llamada �copy-on-write� ,este método se basa en asignar los mismo bloques para los distintos archivos al momento de reservar espacio libre,pero al momento de persistir la información se asignan bloques nuevos para el archivo en cuestión.[11]

5.2.4. Sistema de archivos EXT-4, HFS+, ZFS

Estos sistemas de archivos utilizan el método llamado �delayed allocation�, este consiste en retrasar la reservade bloques hasta que la información esté a punto de ser escrita en el disco, a diferencia de otros sistemas dearchivos, los cuales reservan los bloques necesarios antes de ese paso. Esto mejora el rendimiento y reduce lafragmentación al mejorar las decisiones de reserva de bloques basada en el tamaño real del archivo.[14]

5.2.5. Ventajas y desventajas

Varios de los sistemas operativos no ejecutan el proceso de desfragmentación de manera automática, requierenque el usuario lo indique. Esto es una gran desventaja ya que muchos usuarios no conocen la existencia de estasherramientas.Algunos sistemas de archivo implementan diferentes técnicas para disminuir la fragmentación, otros no, lo cuales una desventaja.

5.3. Líneas de investigación sobre técnicas para evitar la fragmentación en sistemas

de archivos modernos

En esta sección se tratarán en detalle técnicas utilizadas para evitar la fragmentación en sistemas de archivosUnix y NTFS.

5.3.1. Sistemas de archivos Unix

Como se mencionó en secciones anteriores, cuando se graban los bloques de un archivo, estos pueden ubicarse ensecciones no contiguas de la unidad de almacenamiento; esto provoca que al momento de leer dichos bloques, launidad de lectura necesite realizar movimientos por varias pistas de la unidad de almacenamiento. El efecto derealizar dichos movimientos es que perjudica la performance del sistema de archivos.

La solución plateada por Unix para resolver este problema es la llamada agrupación por cilindros (ima-gen 5.4); esta técnica se basa en dividir la unidad de almacenamiento en cilindros, es decir, agrupar un númerode pistas de la unidad de almacenamiento en un cilindro.[12]Al momento de realizar la persistencia de los bloques del archivo se ubican según la política que se describe en lasiguiente sección. De esta manera se reduce el tiempo de acceso a los bloque de los archivos ya que el movimientode la unidad de lectura sobre la unidad de almacenamiento se reduce de manera considerable ya que el tiempode acceso está totalmente relacionado con el tiempo de posicionamiento de la unidad de lectura, por lo tanto, aldisminuir dicho tiempo reducimos el tiempo de acceso.



Cuando se necesita asignar espacio a un archivo o directorio, se ejecuta la siguiente heurística que consta de cuatroetapas:

1. Se busca el bloque más cercano al actual dentro del mismo cilindro.

2. Si no se encuentra ningún bloque disponible en el mismo cilindro, se asigna un bloque de otro cilindrodel mismo grupo de cilindros.

3. Si el grupo de cilindros está totalmente lleno, se utiliza una función de hash para obtener el número deotro grupo de cilindors en el que se repiten los pasos uno y dos.

4. Finalmente, si el paso tres falla, se busca en todos los grupos de cilindros.

La heurístia presentada es la utilizada para la asignación de bloques a los archivos y directorios.

Cada grupo de cilindros contiene información acerca de los bloques que almacena:

1. Un Bitmap que indica los bloques libres.

2. La lista de i-nodos que contiene.

3. Una copia del superbloque.

En el trabajo [12] se realizaron pruebas relacionadas con el rendimiento de esta técnica, demostraron que generamejoras en la performance ya que los tiempos de acceso bajaron con respecto a un sistema de archivos que trabajasin respetar el principio de localidad.



5.3.2. Sistemas de archivos NTFS

Basado en el principio de localidad los clusters de un archivo se almacenan de manera contigua siempre quesea posible. Cada conjunto de clusters contiguos de un archivo se describe mediante un registro; si un archivoestá formado por más de un conjunto de clusters contiguos se utiliza un conjunto de registros para referenciarlos,por ejemplo, si el archivo está formado por los clusters 899 al 1000 y los 1100 al 1200 se tendrá dos registros querepresente ambos conjuntos. Cada registro comienza con un encabezado que proporciona el desplazamiento de losdatos del primer conjunto dentro del registro, luego el desplazamiento del siguiente conjunto, y así sucesivamente.Cada encabezado va seguido de uno o más pares, cada uno de los cuales proporciona la dirección del primercluster del conjunto (de clusters contiguos) y la longitud del conjunto; la dirección es respecto al comienzo de lapartición. La imagen 5.5 representa un registro de la MFT para tres conjuntos de clusters consecutivos.

En el caso en que el archivo sea tan grande o tan fragmentado y la información de los clusters no entre enun registro de la MFT se utilizan varios registros para este �n. Tendremos un registro base y varios registros deextensión según se necesite.

En el caso en que se necesiten tantos registros de la MFT tal que no haya espacio su�ciente en la MFT base paralistar todos sus índices se utilizan clusters extras (no pertenecen a la MFT base) para colocar esta información,de esta manera puede crecer todo lo que sea necesario.

En la 5.6 se muestra una entrada en la MFT para un directorio pequeño. El registro contiene varias entradasde directorios, cada una de las cuales describe a un archivo o directorio. Cada entrada tiene una estructura delongitud �ja seguida de un nombre de archivo de longitud variable. La parte �ja contiene el índice de la entradaen la MFT para el archivo, la longitud del nombre del archivo y una variedad de campos y �ags adicionales. Para



buscar una entrada en un directorio se debe examinar todos los nombres de archivo en el registro.

En el caso de directorios grandes se utiliza un formato diferente. En vez de listar todos los archivos en for-ma lineal, se utiliza un árbol B+ para que sean búsquedas óptimas.

Para realizar la búsqueda del archivo C:\foo\bar se realizan las siguientes acciones, se efectúa un análisis de la ruta\foo\bar que comienza en el directorio raíz C: cuyos bloques se pueden encontrar desde la entrada 5 de la MFT(por ejemplo), la cadena �foo� se busca en el directorio raíz el cual devuelve el índice en la MFT del directorio foo.Luego se busca en este directorio la cadena �bar�, que se re�ere al registro de la MFT para este archivo. Luegode realizar las comprobaciones de seguridad se busca el registro de la MFT para el atributo ::$DATA, que es el�ujo de datos predeterminado.

Con este técnica se logra tener la información que forma a los archivos de manera tal que se cumple el principiode localidad en una buena medida, y por lo tanto la performance crece.

5.3.3. EXT-4

Este sistema de archivos introduce tres nuevas técnicas para reducir la fragmentación de los archivos, estas sonextents, preallocate y allocate-on-�ush.[15]

Extents: Ext3 utiliza un alocador de bloques que decide cuáles de los que se encuentran libres van a serutilizados para escribir los datos, para llevar a cabo esta acción se realiza una llamada por bloque, lo cuales ine�ciente por ser demasiadas llamadas las que se realizan.Para mejorar este aspecto Ext4 incorpora un alocador multi-bloques que en una sola llamada aloca todoslos bloques (en lo posible de manera contigua) necesarios, este conjunto de bloques es denomina extends.



Las estructuras utilizadas phara el funcionamiento de esta técnica son las siguientes:

/*

* This is the extent on-disk structure. * It's used at the bottom of the tree.

*/

struct ext4_extent {

__le32 ee_block; /* �rst logical block extent covers */

__le16 ee_len; /* number of blocks covered by extent */

__le16 ee_start_hi; /* high 16 bits of physical block */

__le32 ee_start_lo; /* low 32 bits of physical block */

};h

/*

* This is index on-disk structure.

* It's used at all the levels except the bottom.

*/

struct ext4_extent_idx {

__le32 ei_block; /* index covers logical blocks from 'block' */

__le32 ei_leaf_lo; /* pointer to the physical block of the next, level. leaf or next index could be there */

__le16 ei_leaf_hi; /* high 16 bits of physical block */

__u16 ei_unused;

};

Estas dos estructuras representan las hojas (ext4_extent) y los nodos internos (ext4_extent_idx) del árbolque se utiliza para acceder al extend.

Preallocate: Para incrementar la probabilidad de que los bloques asignados a un Extend sean contiguoses necesarios reservarlos lo más rápido posible, para esto se implementó una nueva SystemCall (preallocate)al kernel de Linux, esta operación realiza la reserva de bloques cuando es invocada.

Allocate-on-�ush: Una técnica que tiene la misma �nalidad que Preallocate (trabajan de manera difer-ente y tienen el mismo propósito) es Allocate-on-�ush, esta consiste en retrasar la reserva de bloques hastaque la información esté a punto de ser persistida en la unidad de almacenamiento. Esta técnica mejora elrendimiento y reduce la fragmentación al mejorar las decisiones de reserva de memoria basada en el tamañodel archivo.

5.4. Bu�er-cache para la optimización de tiempos de acceso

Como se mencionó anteriormente, cuando se accede a un bloque tenemos tres tiempos para analizar:

1. El tiempo que tardan los cabezales en posicionarse en el cilindro donde se encuentra el sector a leer o escribir(tiempo de seek).

2. El tiempo de rotación para que el sector a leer o escribir se encuentre con el cabezal(tiempo de latencia).

3. El tiempo de lectura o escritura (tiempo de transferencia).

Estos tiempos no son menores, por lo tanto se pueden aplicar técnicas para reducirlos, una de estas es la utilizaciónde bu�er-cache.



5.4.1. Bu�er-cache

El bu�er-cache es una cache de bloques y su objetivo es minimizar accesos a la unidad de almecenamiento,el por qué de este objetivo es que el acceso a la unidad de almacenamiento para acceder a bloques es de variosórdenes mayor que el tiempo de acceso a la memoria principal.

Una manera de implementar esta técnica es mediante listas enlazadas en memoria donde cada dispositivo dealmacenamiento tiene asociada una o más listas de bloques, las mismas se acceden mediante una hash que secalcula con la dirección del dispositivo.

La imagen 5.7 muestra una ejempli�cación de la implementación del bu�er-cache mediante listas enlazadas.

5.4.2. Política de reemplazo de bloques

En ocasiones se quiere insertar un nuevo elemento en alguna de las listas estando llena, cuando esto ocurre sedebe implementar algún tipo de política de reemplazo.



Una posibilidad (y la más utilizada) es la técnica denominada LRU, esta consiste en reemplazar el elemento quetiene mayor tiempo sin accederse.

La imagen 5.8 representa el proceso de reemplazo de un bloque según la política LRU.

Cada uno de los bloques cargados en las listas tienen un status que re�eja su estado. A modo de optimización,cada bloque se mantiene en memoria sin persistir su información en la unidad de almacemamiento hasta que sereemplace por otro, por lo tanto en el momento en que se reemplace se analizará su status para saber si debe serpersistido en la unidad de almacenamiento o no.

A continuación se presenta una heurística que representa este mecanismo.

1) Se intenta insertar un nuevo bloque en la lista.

2) En caso de que haya espacio se inserta.

3) En caso de no poder insertarlo se busca el bloque a reemplazar.

4) Si el bloque que se va a quitar de la lista está modi�cado se persiste en la unidad de almacenamiento.



5) Se inserta el nuevo bloque en la lista.

5.4.3. Sincronización para el reemplazo de bloques

Esta técnica tiene problemas de sincronización al momento de querer modi�car o reemplazar uno de los bloquesque está en alguna de las listas. Un método para evitar este problema es analizar el status del bloque, si el statusindica que el bloque está siendo utilizado por otro proceso, el proceso que quiere tomar el bloque queda en esperahasta que quede libre. Este es el mecanismo más tradicional y más simple para sincronizar el acceso a los nodosde la lista.

La imagen 5.9 representa el proceso de sincronización de bloques.

A continuación se presenta una heurística para este proceso:

1) Se accede a un bloque de la lista.



2) Si está libre es tomado, caso contrario se ejecuta el paso 4.

3) Se modi�ca a tomado el status del bloque.

4) Se Espera en una cola a que el bloque sea liberado.

5.4.4. Optimización en la performance del bu�er-cache por medio de algoritmos que utilizaninformación de la carga del sistema

En el trabajo [17] se analizó una optimización para el método de bu�er cache que consiste en lo siguiente, sepropone una serie de algoritmos que permiten realizar la escritura de los bloques de manera sincrónica. Estosalgoritmos utilizan la cantidad de procesos corriendo en el sistema y la longitud de la cola de la cache, estainformación se obtiene de manera dinámica durante la ejecución de los algoritmos.El rendimiento de las operaciones en el bu�er-cache se mejora mediante el uso de estos algoritmos que permitenescribir el contenido del bu�er-caché en la unidad de almacenamiento en función de la carga del sistema y laactividad de escritura.

La conclusión del trabajo es que el tiempo de la escritura de un archivo se reduce con la utilización de losalgoritmos que escriben los bloques en la unidad de almacenamiento en función de la tasa de operaciones de es-critura y el número de procesos activos en el sistema. Se demostró que los algoritmos propuestos permitenun mejor rendimiento que un algoritmo que no utiliza información sobre la carga del sistema.

5.4.5. Optimización en la performance del bu�er-cache por medio de mejoras en la política deactualización

Cuando los bloques son modi�cados deben ser escritos en la unidad de almacenamiento, esto se realiza inmedi-atamente, de manera retardada o periódicamente, en el trabajo [18] se analizó una posible optimizaciónpara el método de bu�er cache que consiste en realizar una aplicación aproximada a una política de intervalode actualización periódica, en la que se escribe el bloque en la unidad de almacenamiento cuando cumple ciertotiempo de estar en estado modi�cado.

En la experimentación se ejecutaron dos procesos corriendo al mismo tiempo:

Un generador de escrituras, con�gurado para realizar escrituras cada 30 segundos.

Un generador de lecturas, en el mismo 10.000 bloques son elegidos al azar.

Además se utilizaron dos sistemas de hardware diferentes, uno más rápido que el otro.

En el trabajo en cuestión se ejecutaron varios benchmarks que arrojaron los siguientes resultados, el uso deescritura retardada puede mejorar los tiempos de accesos, pero cuando la escritura retardada se combina conla técnica planteada, los tiempos de respuesta mejoran de manera signi�cativa.

5.4.6. Colas múltiples de reemplazo para el segundo nivel de bu�er-cache

En el trabajo [19] se planteó un nuevo nivel de bu�er cache con un algoritmo que utiliza colas múltiples paraalocar los bloques.

Originalmente el plateo está destinado a servidores distribuidos, pero esta idea puede aplicarse a una computadoralocal que trabaja con los dos niveles de bu�er cache.

La imagen 5.10 representa la estructura necesaria mediante un diagrama de bloques.



El algoritmo utilizado mantiene los bloques en el segundo nivel de bu�er cache, cada bloque tiene asociada unafrecuencia de acceso. Las colas tienen asociadas un rango de frecuencias de accesos admisible, sólo si un bloquetiene el contador de referencias a él dentro de ese rango será alocado en la cola.El algoritmo utiliza n colas que funcionan bajo el algoritmo LRU con algunas variaciones que se describen acontinuación:

En un hit, el bloque es removido de la cola en donde está alocado y es reubicado en la cola que le correspondasegún su frecuencia de acceso.

En un miss, el bloque es ubicado en la cola correspondiente a la menor frecuencia de accesos posible.

A continuación se presenta el pseudocódigo del algoritmo MQ:



La conclusión del trabajo es que el ratio de hits se incrementa en un 10% respecto a la no utilización de la técnicaplateada, por lo tanto los tiempo de acceso a bloques decrecen.


6 ELABORACIÓN DE UNA PROPUESTA DE SOLUCIÓN ALTERNATIVA O SUPERADORA

6. Elaboración de una propuesta de solución alternativa o superadora

La propuesta a la problemática planteada consiste en una técnica que se forma a partir de dos subtécnicas,�Localidad de archivos asociados� y �Ejecución de procesos en background para incrementar laperformance�, estas dos técnicas se van a complementar para formar la propuesta �nal.Además se deben realizar modi�caciones en las estructuras de los sistemas de archivos para darle soporte a estanueva técnica, en el actual trabajo se plantearán las nuevas estructuras y modi�caciones en general, quedandopara trabajos a futuros realizar las implementaciones de las mismas.

6.1. Localidad de archivos asociados

Con frecuencia sucede que un proceso accede a un conjunto de archivos para leerlos o manipularlos. Este fenómenopermite plantear que estos archivos están relacionados.

La técnica de Localidad de archivos asociados se basa en los siguientes principios:

1. Favorece a la performance que los archivos relacionados estén ubicados lo más cercanamente posible dentro dela unidad de almacenamiento (principio de localidad), el caso ideal es que estén ubicados adyacentemente.

2. Favorece a la performance que los bloques que forman un archivo estén ubicados lo más cercanamente posibledentro de la unidad de almacenamiento (archivos no fragmentados), el caso ideal es que estén ubicadosadyacentemente.

6.1.1. Algoritmo de principio de localidad en archivos asociados

Para cumplir con el principio de localidad, esta técnica plantea lo siguiente:

Todos los archivos accedidos por un mismo proceso están relacionados, por lo tanto debe armarse el productocartesiano de relaciones entre los mismos. El mismo método debe repetirse para todos los procesos. Todas lasrelaciones registradas deben fusionarse armando las ternas (archivo 1, archivo 2, cantidad de repeticionesde la relación) y luego deben ser ordenadas según cantidad de ocurrencias y en caso de empate por id de archivo.Los archivos se identi�can mediante un id, en Unix puede ser el número de I-nodo por ejemplo.La información de relaciones generada debe ser fusionada con los resultados históricos de este análisis para todoslos procesos.En caso de que un proceso acceda a un único archivo, no se registra ninguna relación.

A continuación se presenta una ejempli�cación de este proceso.

Universo de archivos: A, B, C, D, E, F, G, H, I



Estas ternas son ordenadas dando el siguiente resultado:

(A, C, 3)

(A, F, 2)

(A, G, 2)

(C, F, 2)

(F, G, 2)

(F, I, 2)

(A, B, 1)

(A, E, 1)

(A, I, 1)

(B, C, 1)

(C, G, 1)

(C, I, 1)

(E, G, 1)

(F, H, 1)

(G, H, 1)

(G, I, 1)

(H, I, 1)

Este resultado se fusiona con el histórico para tener el resultado global de relaciones.

La imagen 6.2 representa el resultado �nal luego de reubicar los archivos según la tabla de relaciones.

Este proceso debe realizar la modi�cación de todas las referencias físicas (por las nuevas ubicaciones) de losbloques de los archivos para mantener la integridad del sistemas de archivos.



6.1.2. Heurística para el algoritmo de principio de localidad en archivos asociados

1) Para cada proceso repetir los siguiente pasos.

2) Obtener todos los archivos referenciados.

3) Armar todas las relaciones posibles para la salida del paso 2.

4) Armar las ternas (archivo 1, archivo 2, cantidad de repeticiones) para la salida del paso 3.

5) Ordenar la salida del paso 4 por cantidad de ocurrencias y en caso de empate por id de archivo.

6) Fusionar la salida del paso 5 con las ternas históricas (evitando repetidas).

7) Volver al paso 2.

8) Ubicar de manera contigua los archivos según la tabla histórica de ternas, en caso de que no existan los bloquescontiguos libres necesarios, ubicarlos de la manera más cercana posible.

6.1.3. Método para evitar la fragmentación en archivos asociados

Los bloques de un archivo (con el pasar del tiempo) dejan de estar ubicados de manera contigua en la unidadde almacenamiento. Como ya se mencionó, este fenómeno provoca la fragmentación y la consiguiente pérdida deperformance.

Para evitar este problema los bloques de los archivos deben ser reubicados de manera contigua.

6.1.4. Resultado de la reubicación de archivos según las relaciones

El resultado de la reubicación de los archivos relacionados nos garantiza disminuir la fragmentación, así comotener ubicados de manera adyacente los que están relacionados. La disminución de la fragmentación ocurreporque al momento de reubicar los archivos (según las relaciones de los mismos) se trata de ubicar los bloques demanera contigua.

De esta manera se logra disminuir el tiempo de seek para la lectura de los bloques, así como también el tiempode seek para el posicionamiento sobre los archivos que utilizan los procesos por estar ubicados de manera adyacente.

La tabla histórica de relaciones de archivos no debe eliminarse nunca, lo que se debe hacer es depurarlaya que con el tiempo se eliminan algunos archivos, esto se analizará en la siguiente sección llamada depuraciónde la tabla histórica de relaciones.

6.2. Persistencia temporal de los accesos a archivos por los procesos

Las relaciones entre archivos deben ser persistidas para poder realizar el algoritmo de principio de localidaden archivos asociados (6.1.1), para esto se plantea la siguiente estructura:

Una cola compartida, la cual tendrá en cada nodo una lista de archivos accedidos por un proceso deter-minado(imagen 6.3), ésta será manipulada por el sistema de archivos.Cada proceso tendrá una lista propia, siempre que se ejecute una llamada al sistema (syscall) para accedera un archivo no presente en dicha lista, ésta será actualizada con el número de id del archivo (acción querealizará el sistema de archivos).



Esta estructura será analizada por un proceso (analizado en secciones posteriores) que se encargará de leer ymodi�car todas las estructuras necesarias para llevar a cabo el algoritmo 6.1.1.

La imagen 6.4 representa la actualización de la cola compartida de archivos accedidos.



6.3. Depuración de la tabla histórica de relaciones

Con el paso del tiempo los archivos tienden a ser eliminados de la unidad de almacenamiento, por lo tanto latabla global de relaciones deja de tener coherencia con respecto a lo archivos almacenados.

La tabla de relaciones crecerá indefectiblemente con el paso del tiempo, por lo tanto su lectura será cada vezmás costosa, esto trae consigo una baja en la performance.

Si bien al momento de reubicar los archivos se analiza que existan, esto no es lo ideal ya que la tabla deberepresentar archivos que existan en la unidad de almacenamiento.

La solución para este problema es depurar la tabla global de relaciones para eliminar aquellas que es-tén formadas por al menos un archivo que no exista.

La imagen 6.5 representa el proceso de depuración.

Como se observa en la imagen, el tamaño de la tabla de relaciones baja considerablemente al ser depurada.

6.4. Módulos que forman la solución

Para la solución de�nitiva se plantea la utilización de una serie de módulos que serán orquestados por otro, acontinuación se detalla cada uno de los ellos.

1. Módulo que implementa el algoritmo del principio de localidad en archivos asociados (6.1.1).

2. Módulo de merge.



3. Módulo de reubicación de bloques.

4. Módulo orquestador.

5. Módulo de depuración de la tabla histórica de relaciones.

6. Módulo de rollback.

6.4.1. Módulo que implementa el algoritmo del principio de localidad en archivos asociados

Este módulo ejecuta las siguientes operaciones:

Accede a la cola compartida de archivos accedidos para obtener las nuevas relaciones generadas desde laúltima vez que se ejecutó.

Ejecuta el algoritmo de principio de localidad de archivos asociados (6.1.1) para el set de datos del puntoanterior.

Guarda la salida del algoritmo en una estructura temporal que será accedida posteriormente por el módulode merge.

6.4.2. Módulo de merge

Este módulo tiene como responsabilidad acceder a la estructura temporal generada por el módulo del punto 6.4.1y realizar un merge de los datos de dicha estructura con la tabla histórica de relaciones.

El resultado de este proceso es la tabla histórica de relaciones actualizada y lista para ser procesada por elmódulo de reubicación de bloques.

6.4.3. Módulo de reubicación de bloques

Este módulo debe accede a la tabla histórica de relaciones y por cada entrada de la misma realiza la operaciónde reubicación de bloques.

Este proceso se ejecuta para la tabla completa y debe mantener actualizado el número de registro que estáejecutando, cuando procesa el último registro �naliza su ejecución y el número de registro de la tabla histórica derelaciones se setea en uno.

La reubicación de bloques se efectúa generando una copia (que cumple el principio de localidad) de losbloques de los archivos, una vez efectuada esta operación se modi�can todas las referencias a los archivos quepertenecen a los bloques reubicados de manera tal que al acceder a los mismos se acceda a los nuevos bloques.La última acción es marcar como libre los bloques que anteriores formaban los archivos para que puedan serutilizados cuando sea necesario.

6.4.4. Módulo orquestador

Este módulo es el encargado de orquestar la ejecución de todos los demás, la manera de orquestar es la que sepresenta en la imagen 6.6.



6.4.5. Heurística para la ejecución del módulo de orquestación

1) Ejecución del módulo del principio de localidad y generación de la estructura temporal con el resultado.

3) Ejecución del módulo de merge.

4) Ejecución del módulo de reubicación de bloques.

5) Para cada entrada en la tabla histórica de relaciones ejecutar la operación de reubicación.



6.4.6. Mecanismo de log para mantener la consistencia en caso de falla

En ocasiones puede ocurrir que durante la ejecución del módulo orquestador el sistema falle (corte de luz porejemplo), esto puede generar que el sistema de archivos deje de mantener la consistencia.

Para solucionar este problema se plantea lo siguiente, crear una estructura de log que sea analizada por elsistema de archivo cuando inicia y en caso de ser necesario ejecute las acciones necesarias para que vuelva a tenerconsistencia.

La estructura planteada es la que se presenta en la imagen 6.7.

Cada vez que el módulo de reubicación inicie su operación sobre ambos archivos, se vacía la estructura y se setea elcampo START para indicar el comienzo de dicha operación, así como el segundo campo que indica el número deregistro de la tabla histórica de relaciones que está siendo procesado, estos dos campos se setean de maneraconjunta. Cuando �nalice completamente la ejecución de reubicación de bloques y modi�cación de referencias sesetea el campo END que indica que se terminó de ejecutar de manera satisfactoria el proceso de reubicación.El proceso de log se realiza siempre que se ejecute la reubicación de bloques para un registro de la tabla históricade resultados.

Cuando arranca el sistema de archivos se analiza esta estructura, en caso que exista el campo START y noel campo END implica que hubo un error durante la ejecución del módulo de reubicación para el número deregistro en cuestión, por lo tanto lo que se hace es deshacer los cambios realizados, que en el peor de los casoses marcar como libre a todos los nuevos bloques que fueron copiados. Para llevar a cabo esta acción es necesariotener persistidos los datos correspondientes a los nuevos bloques, estos se persistirán en una estructura que seplantea en la imagen 6.8.

Luego de realizar las acciones necesarias se resetea la estructura de log.

Este mecanismo de log es el utilizado por los motores de base de datos para mantener consistencia luego deuna falla en el sistema.

En esta estructura se guarda la referencia a los nuevos bloques creados durante el proceso de reubicación. Cadavez que se termina de procesar un registro de la tabla histórica de relaciones, esta estructura debe ser vaciada yaque el llegar a ese punto de la ejecución indica que el registro procesado no sufrió ningún problema.Siempre que el proceso de reubicación termine de copiar un bloque, se debe agregar la referencia a ese bloqueen esta estructura, esto es necesario para que al iniciar el sistema de archivos se realice el rollback de estoscambios si hubo un error, es decir, los nuevo bloques van a ser marcados como libres. Esta tarea será llevada a



cabo por el módulo de rollback.

6.4.7. Control de la concurrencia

Durante la ejecución del módulo orquestador pueden ocurrir los siguientes escenarios que son potencialmentepeligrosos para la concurrencia:

1. Se ejecuta la reubicación de algún archivo que está siendo utilizado por algún proceso.

2. Un proceso intenta acceder a un archivo que está siendo reubicado.

Las soluciones que se plantean para cada uno de los escenarios son respectivamente las siguientes:

1. Simplemente se descarta la ejecución de cualquier registro (de la tabla histórica de relaciones) que tenga almenos un archivo que está siendo utilizado por otro proceso.

2. En este escenario, el sistema de archivos no dará permiso de acceso al archivo en cuestión.

6.4.8. Módulo de rollback

Este módulo es el encargado de llevar a cabo la eliminación de los últimos cambios no aplicados. Al iniciarel sistema realizará el análisis de la estructura que �gura en la imagen 6.8, y en caso de ser necesario realiza elrollback.Como todos los módulos, es ejecutado por el módulo orquestador.

6.4.9. Módulo de depuración de la tabla histórica de relaciones

Este módulo debe llevar a cabo la tarea de depuración de la tabla histórica de relaciones analiza en la sección 6.3.El módulo orquestador es el encargado de realizar la ejecución del módulo en cuestión.

6.4.10. Frecuencia de ejecución del módulo orquestador

El módulo orquestador tiene tres funciones que son las siguientes:

1. Ejecutar elmódulo de rollback, esta ejecución se efectúa cuando inicia el sistema de archivos, es decir, esteejecutará el módulo orquestador indicándole que realice la acción de rollback en cambios que no mantienenla consistencia.

2. Ejecutar el módulo del principio de localidad en archivos asociados, esta ejecución se efectúa enintervalos de un cierto tiempo que es un parámetro de con�guración del sistema. Siempre que se intenteejecutar este módulo se analizará si la cantidad de registros presentes en la cola de relaciones es mayor a uncierto parámetro del sistema.

3. Ejecutar el módulo de depuración de la tabla histórica de relaciones, esta ejecución se efectúa enel mismo intervalo que el módulo del principio de localidad en archivos asociados, pero de maneraintercalada con este.



6.5. Modi�caciones necesarias en Sistema de archivos NTFS para soportar esta

técnica

En esta sección se describen las nuevas estructuras que son necesarias en un Sistema de archivos para soportaresta técnica, además se hace referencia a los cambios necesarios en los Sistemas de archivos en general.

6.5.1. Cola compartida de relaciones

Esta estructura contiene la información sobre las nuevas relaciones generadas luego de que se ejecutó el procesode reubicación de bloques, la estructura física que se plantea para la misma es un archivo con registros de longitudvariable.El encabezado del archivo tiene la cantidad de registros presentes, este dato es analizado para determinar si sedebe o no ejecutar el módulo del principio de localidad en archivos asociados.Cada registro del archivo está formado por un campo header, que tiene la longitud del campo siguiente campoque es el data, éste contiene las relaciones presentes en el registro.



6.5.2. Tabla histórica de relaciones

Para esta estructura se plantea utilizar un archivo formado por registros de longitud �ja, cada registro estáformado por los siguientes campos:

Identi�cador1: Identi�cador del primer archivo de la relación.

Identi�cador2: Identi�cador del segundo archivo de la relación.

Cantidad de repeticiones: Cantidad de repeticiones de la tupla de archivos relacionados.

6.5.3. Estructura utilizada para identi�cación de inconsistencias tras una falla

Esta estructura está formada por tres campos que son los siguientes:

Representación del comienzo de la transacción.

Número de registro de la tabla histórica de relaciones procesado.

Representación del �nal de la transacción.



6.5.4. Estructura utilizada para por el proceso de rollback

La organización planteada para esta estructura es un archivo de registros de longitud �ja donde cada registrotiene una referencia a uno de los bloques que fueron copiados en el proceso de reubicación de bloques.



6.5.5. Modi�caciones generales en los Sistemas de archivos

Las modi�caciones generales que deben tener los sistemas de archivos para soportar la técnica planteada en elpresente trabajo son las siguientes:

Todas las nuevas estructuras planteadas en el punto anterior deben ser ubicadas en regiones de la unidadde almacenamiento reservadas por el sistema de archivos para conocer su ubicación y poder accederlas.

Es necesario tener un id por archivo para poder identi�carlo y de esa manera acceder a sus bloques.

El sistema de archivos debe poder acceder a un bloque mediante su dirección física para marcarlo comolibre en el proceso de rollback


7 EVALUACIÓN ANALÍTICA Y EXPERIMENTAL DE LA PROPUESTA

7. Evaluación Analítica y Experimental de la Propuesta

Cuando se accede a un archivo existen tres tiempos intervinientes en la operación:

1. El tiempo que tardan los cabezales en posicionarse en el cilindro donde se encuentra el sector a leer o escribir(tiempo de seek).

2. El tiempo de rotación para que el sector a leer o escribir se encuentre con el cabezal(tiempo de latencia).

3. El tiempo de lectura o escritura (tiempo de transferencia).

7.1. Evaluación analítica

El tiempo de acceso a un archivo puede ser representado con la siguiente expresión[20][21]:

T =n∑0

S (n)un∑0

L (n)un∑0

T (n)

Donde:

El subíndice n representa la cantidad de bloques que forman el archivo.

n∑0

S(n) es la sumatoria de los tiempos de seek generados por el acceso a todos los bloques que forman el

archivo.[20]

n∑0

L(n) es la sumatoria de los tiempos de latencia generados por el acceso a todos los bloques que forman

el archivo.[20]

n∑0

T (n) es la sumatoria de los tiempos de transferencia generados por el acceso a todos los bloques que

forman el archivo.[20]

7.1.1. Hipótesis sobre el tiempo de seek

Se plantea la siguiente hipótesis sobre el tiempo de seek, Yi ∈ N se cumple que S(i)=S(i+ 1), es decir, dadosdos cilindros cualquiera que sean consecutivos, el tiempo para trasladarse de uno al otro es el mismo.

Bajo esta hipótesis se puede pensar en la siguiente expresión

S (n) = Q× abs (C (n)− C (n− 1))

donde Q es una constante que representa el tiempo en trasladarse de un cilindro a otro estando ambos ubicadosde manera consecutiva. C (n) representa el número de cilindro en el que se encuentra el bloque n, lo mismo aplicapara la expresión C (n− 1) .[21]

7.1.2. Hipótesis sobre el tiempo de latencia

Se plantea la siguiente hipótesis sobre el tiempo de latencia, Yi ∈ N se cumple que L(i)=L(i+ 1), es decir,dado dos bloques cualquiera que sean consecutivos, el tiempo para trasladarse de uno al otro es el mismo.

Bajo esta hipótesis se puede pensar en la siguiente expresión

L (n) = M × abs (B (n)−B (n− 1))

donde M es una constante que representa el tiempo en pasar de un bloque a otro estando ambos ubicados demanera consecutiva. B (n) representa el número de bloque físico en el que se encuentra el bloque n, lo mismoaplica para la expresión B (n− 1) .[21]



7.1.3. Hipótesis sobre el tiempo de transferencia,

Planteando la siguiente hipótesis sobre el tiempo de transferencia, Yi, j ∈ N se cumple que T (i)=T (j), esdecir, que el tiempo de transferencia es el mismo para todos los bloques, se puede pensar en la siguiente expresiónpara representar el tiempo de acceso a un archivo

T =n∑0

S (n)un∑0

L (n)u nK

donde K es una constante que representa el tiempo de transferencia de un bloque.

Como nK sigue siendo una contante, la expresión se puede simpli�car aún más[21]

T =n∑0

S (n)un∑0

L (n)uK

7.1.4. Expresión general del tiempo de acceso

Teniendo en cuenta las hipótesis anteriores sobre los tres tiempos intervinientes en el acceso, el tiempo de accesoa un archivo se puede representar con la siguiente expresión

T =n∑0

Q× abs (C (n)− C (n− 1))un∑0

M × abs (B (n)−B (n− 1))uK

siendo la expresión de�nitiva[21]

T = Q×n∑0

abs (C (n)− C (n− 1))uM ×n∑0

abs (B (n)−B (n− 1))uK

7.1.5. Grá�co del tiempo de seek en función de la distancia entre cilindros

Como se mencionó, la expresión para representar el tiempo de seek es

S (n) = Q× abs (C (n)− C (n− 1))

es una función de dos variables (Q es una constante), pero si se toma a C (n− 1) como una constante P laexpresión queda reducida a una función de una variable, es decir

S (n) = Q× abs (C (n)− P )

esta expresión se puede utilizar para modelizar la variación del tiempo de seek por el acceso a un bloque enrelación con el cilindro en el que se encuentra el bloque accedido anteriormente (constante P).

La expresiónS (n) = Q× abs (C (n)− P )

es equivalente a la siguiente función partida

S (n) =

{Q× (C (n)− P ) si C (n) > P

Q× (P − C (n)) si C (n) < P



El grá�co anterior muestra la función S(n) para el caso en que P tenga el valor 5, el dominio de la función sontodos los números naturales. En él se oberva que S(n) crece de manera lineal con respecto a la separación de loscilindros en los que se encuentran los bloques.[21]Cabe hacer la aclaración de que el valor 5 es a modo de ejempli�cación.

7.1.6. Grá�co del tiempo de latencia en función de la distancia entre bloques

Como se mencionó, la expresión para representar el tiempo de latencia es

L (n) = M × abs (B (n)−B (n− 1))

es una función de dos variables (M es una constante), pero si se toma a B (n− 1) como una constante Z laexpresión queda reducida a una función de una variable, es decir

L (n) = M × abs (B (n)− Z)

esta expresión se puede utilizar para modelizar la variación del tiempo de latencia en relación con la posición delbloque accedido anteriormente (constante P) independientemente del cilindro en el que se encuentren.

La expresiónL (n) = M × abs (B (n)− Z)

es equivalente a la siguiente función partida

L (n) =

{M × (B (n)− Z) si B (n) > Z

M × (Z −B (n)) si B (n) < Z



El grá�co anterior muestra la función L(n) para el caso en que Z tenga el valor 5, el dominio de la función sontodos los números naturales. En él se oberva que L(n) crece de manera lineal con respecto a la separación de losbloques(independientemente de los cilindros en los que se encuentren).[21]Cabe hacer la aclaración de que el valor 5 es a modo de ejempli�cación.

El grá�co anterior y el que representa el tiempo de seek en función de la distancia entre cilindros(7.1.5) notienen por qué tener la misma pendiente ya que los valores Q y M pueden no qué ser iguales (son las pendientesde las rectas).

7.1.7. Observaciones �nales sobre el tiempo de acceso

La expresión �nal del tiempo de acceso a un archivo es

T = Q×n∑0

abs (C (n)− C (n− 1))uM ×n∑0

abs (B (n)−B (n− 1))uK

por lo tanto la única vía para reducir este tiempo es reducir las distancias físicas entre los bloques que forman elarchivo, cuanto más cercanos estén los bloques más se reducirá el tiempo de accceso, siendo el caso óptimo ubicartodos los bloques de manera consecutiva en el mismo cilindro de la unidad de almacenamiento.

7.2. Evaluación Experimental

7.2.1. Descripción de la simulación

La evaluación práctica se basa en la simulación de los accesos a diferentes archivos efectuados por los procesos enun sistema de archivos.

Para esto se realizaron varios módulos que interactúan entre si y son descriptos a continuación:

Módulo FileSystem: Encargado de ejecutar los accesos para cada uno de los procesos con�gurados. Estemódulo genera la información de las relaciones de archivos (principio de localidad basado en relaciones) ylos tiempos de acceso a los mismos.



Módulo LocalityPrinciple: Accede a la cola de relaciones y genera un resultado temporal querespeta el algoritmo presentado en la sección 6.1.1

Módulo Merge: Accede a la tabla histórica de relaciones y al resultado temporal generado por el móduloLocalityPrinciple y realiza el merge entre ambas respetando lo planteado en la sección 6.1.1

Módulo Relocation: Realiza la reubicación de bloques respetando el principio de localidad segúnrelaciones.

Módulo Orchestrator: Realiza la orquestación de los módulos LocalityPrinciple, Merge y Reloca-tion.

Módulo Con�gurations: Encargado de acceder a las diferentes con�guraciones de la simulación.

Módulo Statics: Encargado de persistir las estadísticas obtenidas.

La simulación se basa en la ejecución de los procesos, cada uno de estos realiza una serie de accesos a archivos,los procesos se crean a partir de una con�guración, en ella además, por cada proceso, se especi�ca una lista dearchivos a los que debe acceder, a continuación se ejempli�ca la con�guración de procesos:

process.count=2

process.id.0=123process.access.0=30,RANDOM,9000|1001,SEQUENTIAL,500

process.id.1=321process.access.1=31,RANDOM,9000|2100,RANDOM,8777

Esta con�guración indica que se deben ejecutar dos procesos, el primer proceso tiene id 123, realiza el accesoa dos archivos, el primer acceso realizado es al archivo 30, de manera random y accede a 9000 de sus bloques.

El acceso a los archivos puede ser de manera random o secuencial, el acceso randon ejecuta accesos de maneraaleatoria a cualquier de sus bloques, el acceso secuencial implica acceder de manera coonsecutiva a los bloquesdel archivo comenzando desde el primero, en caso de que se ejecuten más accesos que bloques tiene el archivo sevuelve a comenzar desde el primer bloque.

Los archivos existentes en el sistema de archivos simulado se crean a partir de la siguiente con�guración:

�les.count=2

�le.id.0=30�le.blocks.0=1001,9000|1001,9001|1001,9002

�le.id.1=31�le.blocks.1=2100,9000|2100,9001|2100,9002|2100,9003|2100,9020|2100,9022

Esta con�guración indica que existen dos archivos, el primero id 30, y está compuesto por tres bloques, elprimero de ellos se encuentra en el cilindro 1001 y en la pista 9000.

La cantidad de cilindros y cantidad de bloques por cilindro que tendrá la unidad de almacenamiento simulada(sobre la que se ejecuta el sistema de archivos simulado) se crea a partir de la siguiente con�guración:

tracks.count=5000

bloks.by.tracks=10000

Esta con�guración indica que la unidad de almecenamiento tiene 5000 cilindros (o pistas) y 10000 bloquespor cilindro.



El módulo FileSystem recibe estas con�guraciones y en base a ellas realiza la ejecución de todos los procesosy para cada uno de ellos todos sus accesos a los archivos que tiene con�gurado, se mide el tiempo en que cadaproceso realiza el acceso a todos los archivos, este dato será persistido por el módulo de estadísticas luego.

Este proceso se repite dos veces, entre ella se ejecuta el módulo Orchestrator para aplicar el principio delocalidad platenado en la sección 6.1.1

Se tomarán las estadísticas de ambas ejecuciones para luego compararlas y obtener conclusiones.

Dado que nos interesa analizar los tiempos de acceso de seek y latencia, y a modo de modelización de losmismos, se le asignará un peso a cada cilindro y a cada bloque recorrido para acceder al próximo bloque, por lotanto los tiempos se miden en función de estos pesos, por ejemplo, si el bloque n está ubicado en la tupla (10,200) (nro. de cilindro más nro. de bloque), y el bloque n+1 está ubicado en la tupla (11, 250), el tiempo pararealizar el acceso al bloque n+1 (estando ubicados en el bloque n) será de (11 - 10) x Peso cilindros + (250 - 200)x Peso bloques.



7.2.2. Diagrama de arquitectura de la simulación



7.2.3. Diagrama de secuencia de la simulación

7.2.4. Código fuente de módulo FileSystem

package t e s i s . core . f i l e s y s t em . impl ;



import java . u t i l . ArrayList ;import java . u t i l . C o l l e c t i o n s ;import java . u t i l . L i s t ;import java . u t i l .Map;

import org . apache . l o g 4 j . Logger ;import org . spr ingframework . beans . f a c t o r y . annotat ion . Required ;

import t e s i s . core . f i l e s y s t em . Fi leSystem ;import t e s i s . core . f i l e s y s t em . r e s o l v e r . B l o ckSe l e c to rReso lv e r ;import t e s i s . core . f i l e s y s t em . r e s o l v e r . s t r a t e g i e s . B l o ckSe l e c to r ;import t e s i s . core . f i l e s y s t em . r e s o l v e r . s t r a t e g i e s . model . BlockSe lectorData ;import t e s i s . core . model . f i l e s . Block ;import t e s i s . core . model . p roc e s s . Access ;import t e s i s . core . model . r e l a t i on sh i p s qu eu e . Relat ionshipsQueue ;

pub l i c c l a s s Fi leSystemImpl implements Fi leSystem{

f i n a l s t a t i c Logger LOGGER = Logger . getLogger ( Fi leSystemImpl . c l a s s ) ;

p r i va t e B lockSe l e c to rReso lv e r b l o ckSe l e c t o rRe s o l v e r ;p r i va t e Block currentHeadBlock = nu l l ; // Current block o f head

pub l i c L i s t<Long> execute ( t e s i s . core . model . f i l e s y s t em . Fi leSystem f i l eSys tem ,Lis t<t e s i s . core . model . p roc e s s . Process> process , Map<Long , L i s t<Block>> f i l e s ,Relat ionshipsQueue r e l a t i onsh ip sQueue ) {

List<Long> accesTimes = new ArrayList<Long>() ;

i n t execut ionsCount = f i l eSy s t em . getExecutionsCount ( ) ;f o r ( i n t i =0; i < executionsCount ; i++){

f o r ( t e s i s . core . model . p roc e s s . Process proc : p roce s s ) {Lis t<Long> r e l a t i o n s h i p s F i l e = new ArrayList<Long>() ;Map<Long , L i s t<Long>> r e l a t i o n s h i p s = re l a t i on sh ip sQueue . g e tRe l a t i on sh ip s ( ) ;

i f ( r e l a t i o n s h i p s . containsKey ( proc . ge t Id ( ) ) ) {r e l a t i o n s h i p s F i l e . addAll ( r e l a t i o n s h i p s . get ( proc . ge t Id ( ) ) ) ;

}

p roce s sA l lAcce s s ( proc . getAccess ( ) , accesTimes , f i l e s , r e l a t i o n s h i p s F i l e ) ;

i f ( ! r e l a t i o n s h i p s . containsKey ( proc . ge t Id ( ) ) ) {r e l a t i o n s h i p s . put ( proc . ge t Id ( ) , r e l a t i o n s h i p s F i l e ) ;

} e l s e {in s e r tNotRepea tF i l e s Id ( r e l a t i o n s h i p s . get ( proc . ge t Id ( ) ) , r e l a t i o n s h i p s F i l e ) ;

}

Co l l e c t i o n s . s o r t ( r e l a t i o n s h i p s . get ( proc . ge t Id ( ) ) ) ;

LOGGER. debug (" Proces ing proce s s " . concat (Long . t oS t r i ng ( proc . ge t Id ( ) ) ) .concat (" o f i t e r a t i o n ") . concat ( In t eg e r . t oS t r i ng ( i ) ) ) ;

}}

re turn accesTimes ;}

p r i va t e void in s e r tNotRepea tF i l e s Id ( Li s t<Long> r e l a t i o n s h i p s , L i s t<Long> r e l a t i o n s h i p s F i l e ) {f o r (Long f i l e I d : r e l a t i o n s h i p s F i l e ) {

i f ( ! r e l a t i o n s h i p s . conta in s ( f i l e I d ) ) {r e l a t i o n s h i p s . add ( f i l e I d ) ;

}}

}

p r i va t e void p roce s sA l lAcce s s ( L i s t<Access> access , L i s t<Long> accesTimes ,Map<Long , L i s t<Block>> f i l e s , L i s t<Long> r e l a t i o n s h i p s F i l e s ) {long time = 0 ;

f o r ( Access acc : a c c e s s ) {



time = time + getAccessTime ( acc , f i l e s ) ;

i f ( r e l a t i o n s h i p s F iAn á l i s i s de l o s r e s u l t a d o s l e s . indexOf ( acc . g e tF i l e I d ( ) ) == −1){r e l a t i o n s h i p s F i l e s . add ( acc . g e tF i l e I d ( ) ) ;

}}

accesTimes . add (Long . valueOf ( time ) ) ;}

p r i va t e long getAccessTime ( Access access , Map<Long , Li s t<Block>> f i l e s ) {long time = 0 ;Li s t<Block> blocks = f i l e s . get ( a c c e s s . g e tF i l e I d ( ) ) ;

i f ( b locks != nu l l ) {BlockSe lectorData b lockSe l ec to rData = new BlockSe lectorData (

t h i s . currentHeadBlock , b locks ) ;

B l o ckSe l e c to r b l o c kS e l e c t o r = b l o ckSe l e c t o rRe so l v e r . r e s o l v e ( a c c e s s . getAccessType ( ) ) ;

i n t accessCount = acc e s s . getAccessCount ( ) ;

f o r ( i n t i =0; i < accessCount ; i++){Block toBlock = b l o ckS e l e c t o r . s e l e c t ( b lockSe l ec to rData ) ;time = time + TimesHelper . getTras lat ionTime ( t h i s . currentHeadBlock , toBlock ) ;t h i s . currentHeadBlock = toBlock ;b lockSe l ec to rData . setCurrentBlock ( t h i s . currentHeadBlock ) ;

}}

re turn time ;}

@Requiredpub l i c void s e tB l o ckSe l e c t o rRe so l v e r ( B lo ckSe l e c to rReso lv e r b l o ckSe l e c t o rRe s o l v e r ) {

t h i s . b l o ckSe l e c t o rRe so l v e r = b l o ckSe l e c t o rRe so l v e r ;}

}

7.2.5. Código fuente de módulo TimesHelper

package t e s i s . core . f i l e s y s t emAná l i s i s de l o s r e s u l t ado s . impl ;

import t e s i s . core . model . f i l e s . Block ;

pub l i c c l a s s TimesHelper {

p r i va t e f i n a l s t a t i c i n t FIRST_GLOBAL_ACCESS_TIME = 0 ;p r i va t e f i n a l s t a t i c i n t CHANGE_TRACK_TIME = 10 ;p r i va t e f i n a l s t a t i c i n t CHANGE_BLOCK_TIME = 1 ;

pub l i c s t a t i c long getTras lat ionTime ( Block fromBlock , Block toBlock ) {

i f ( fromBlock == nu l l ) {// i s the f i r s t g l oba l a c c e s sre turn FIRST_GLOBAL_ACCESS_TIME;

}

i n t d i f f e r en c eTra ck s = Math . abs ( fromBlock . getTrackNumber ( ) − toBlock . getTrackNumber ( ) ) ;long d i f f e r e n c eB l o c k s = Math . abs ( fromBlock . getBlockNumber ( ) − toBlock . getBlockNumber ( ) ) ;

r e turn ( d i f f e r en c eTra ck s ∗ CHANGE_TRACK_TIME) + ( d i f f e r e n c eB l o c k s ∗ CHANGE_BLOCK_TIME) ;}

}

7.2.6. Código fuente de módulo LocalityPrinciple

package t e s i s . core . l o c a l i t y p r i n c i p l e . impl ;

import java . u t i l . ArrayList ;



import java . u t i l . C o l l e c t i o n s ;import java . u t i l . L i s t ;import java . u t i l .Map. Entry ;

import org . apache . l o g 4 j . Logger ;

import t e s i s . core . l o c a l i t y p r i n c i p l e . L o c a l i t yP r i n c i p l e ;import t e s i s . core . l o c a l i t y p r i n c i p l e . model . Bas i cRe l a t i on sh ip ;import t e s i s . core . model . l o c a l i t y p r i n c i p l e . TemporaryResult ;import t e s i s . core . model . r e l a t i on sh i p s qu eu e . Relat ionshipsQueue ;import t e s i s . core . model . r e l a t i o n s h i s t o r y t a b l e . Re la t i on sh ip ;

pub l i c c l a s s Loca l i t yPr i n c i p l e Imp l implements Lo c a l i t yP r i n c i p l e {

f i n a l s t a t i c Logger LOGGER = Logger . getLogger ( Loca l i t yPr i n c i p l e Imp l . c l a s s ) ;

pub l i c TemporaryResult execute ( Relat ionshipsQueue re l a t i on sh ip sQueue ) {List<Relat ionsh ip> r e l a t i o n s h i p s = new ArrayList<Relat ionsh ip >() ;L i s t<Bas i cRe la t ionsh ip> ba s i cRe l a t i on sh i p s ;Re l a t i on sh ip re lat ionshipTmp ;

i n t i t e r a t i o n I nd ex = 1 ;f o r ( Entry<Long , Li s t<Long>> re la t i onsh ipQueue : r e l a t i onsh ip sQueue . g e tRe l a t i on sh i p s ( ) .

ent rySet ( ) ) {Lis t<Long> f i l e s I d = re la t i onsh ipQueue . getValue ( ) ;

i f ( f i l e s I d . s i z e ( ) > 1) {ba s i cRe l a t i on sh i p s = Cartes ianProductHelper . getCartes ianProduct ( f i l e s I d ) ;

f o r ( Bas i cRe la t i on sh ip ba s i cRe l a t i on sh i p : b a s i cRe l a t i on sh i p s ) {re lat ionshipTmp=new Re la t i on sh ip ( ba s i cRe l a t i on sh i p . g e t F i r s t F i l e I d ( ) ,

ba s i cRe l a t i on sh i p . ge tSecondFi l e Id ( ) , 1) ;

i n t index = r e l a t i o n s h i p s . indexOf ( re lat ionshipTmp ) ;

i f ( index == −1){r e l a t i o n s h i p s . add ( re lat ionshipTmp ) ;

} e l s e {Re la t i on sh ip r e l a t i o n s h i p = r e l a t i o n s h i p s . get ( index ) ;r e l a t i o n s h i p . s e tRepet i t i onsCount ( r e l a t i o n s h i p . getRepet i t ionsCount ( )+1) ;

}}

}

i t e r a t i o n I nd ex = i t e r a t i o n I nd ex + 1 ;}

Co l l e c t i o n s . s o r t ( r e l a t i o n s h i p s ) ;

r e turn new TemporaryResult ( r e l a t i o n s h i p s ) ;}

}

7.2.7. Código fuente de módulo CartesianProductHelper

package t e s i s . core . l o c a l i t y p r i n c i p l e . impl ;

import java . u t i l . ArrayList ;import java . u t i l . L i s t ;

import t e s i s . core . l o c a l i t y p r i n c i p l e . model . Bas i cRe l a t i on sh ip ;

pub l i c c l a s s Cartes ianProductHelper {

pub l i c s t a t i c L i s t<Bas i cRe la t ionsh ip> getCartes ianProduct ( Lis t<Long> f i l e s I d ) {List<Bas i cRe la t ionsh ip> car te s i anProduct = new ArrayList<Bas i cRe la t ionsh ip >() ;

Bas i cRe la t i on sh ip basicRelationshipTmpOne ;Bas i cRe la t i on sh ip basicRelationshipTmpTwo ;

f o r (Long f i l e I d : f i l e s I d ) {



f o r (Long f i leIdTmp : f i l e s I d ) {i f ( f i l e I d != fi leIdTmp ) {

basicRelationshipTmpOne = new Bas i cRe l a t i on sh ip ( f i l e I d , f i leIdTmp ) ;basicRelationshipTmpTwo = new Bas i cRe l a t i on sh ip ( f i leIdTmp , f i l e I d ) ;i f ( ! ca r t e s i anProduct . conta in s ( basicRelationshipTmpOne ) &&

! car t e s i anProduct . conta in s ( basicRelationshipTmpTwo ) ) {car t e s i anProduct . add ( basicRelationshipTmpOne ) ;

}}

}

re turn car te s i anProduct ;}

}

7.2.8. Código fuente de módulo Merge

package t e s i s . core . merge . impl ;

import java . u t i l . ArrayList ;import java . u t i l . C o l l e c t i o n s ;import java . u t i l . L i s t ;

import t e s i s . core . merge . Merge ;import t e s i s . core . model . l o c a l i t y p r i n c i p l e . TemporaryResult ;import t e s i s . core . model . r e l a t i o n s h i s t o r y t a b l e . Re la t i onsHi s to ryTab le ;import t e s i s . core . model . r e l a t i o n s h i s t o r y t a b l e . Re la t i on sh ip ;

pub l i c c l a s s MergeImpl implements Merge{

f i n a l s t a t i c Logger LOGGER = Logger . getLogger (MergeImpl . c l a s s ) ;

pub l i c Re la t ionsHi s to ryTab le execute ( Re la t ionsHi s to ryTab le r e l a t i on sH i s t o ryTab l e ,TemporaryResult temporaryResult )

{Lis t<Relat ionsh ip> r e l a t i o n sH i s t o r y = new ArrayList<Relat ionsh ip >() ;

copyRelat ionsHis toryTable ( r e l a t i on sH i s t o ryTab l e , r e l a t i o n sH i s t o r y ) ;

i f ( temporaryResult == nu l l | | temporaryResult . g e tRe l a t i on sh i p s ( ) == nu l l ) {re turn new Re lat ionsHi s to ryTab le ( r e l a t i o n sH i s t o r y ) ;

}

LOGGER. debug (" Ca l l i ng addTemporaryResult method") ;addTemporaryResult ( temporaryResult , r e l a t i o n sH i s t o r y ) ;

LOGGER. debug (" Sor t ing c o l l e c t i o n ") ;Co l l e c t i o n s . s o r t ( r e l a t i o n sH i s t o r y ) ;

r e turn new Re la t ionsHi s to ryTab le ( r e l a t i o n sH i s t o r y ) ;}

p r i va t e void copyRe lat ionsHis toryTable ( Re la t ionsHi s to ryTab le r e l a t i on sH i s t o ryTab l e ,L i s t<Relat ionsh ip> r e l a t i o n sH i s t o r y ) {i f ( r e l a t i on sH i s t o r yTab l e != nu l l && re l a t i on sH i s t o r yTab l e . g e tRe l a t i on sh i p s ( ) != nu l l ){

f o r ( Re la t i on sh ip r e l a t i o n s h i p : r e l a t i on sH i s t o ryTab l e . g e tRe l a t i on sh ip s ( ) ) {r e l a t i o n sH i s t o r y . add (new Re la t i on sh ip ( r e l a t i o n s h i p . g e t F i r s t F i l e I d ( ) ,

r e l a t i o n s h i p . ge tSecondFi l e Id ( ) , r e l a t i o n s h i p . getRepet i t ionsCount ( ) ) ) ;}

}}

p r i va t e void addTemporaryResult ( TemporaryResult temporaryResult ,L i s t<Relat ionsh ip> r e l a t i o n sH i s t o r y ) {i n t index ;Re l a t i on sh ip re lat ionshipTmp ;

f o r ( Re la t i on sh ip r e l a t i o n s h i p : temporaryResult . g e tRe l a t i on sh i p s ( ) ) {index=r e l a t i o n sH i s t o r y . indexOf ( r e l a t i o n s h i p ) ;i f ( index != −1){



re lat ionshipTmp=r e l a t i o n sH i s t o r y . get ( index ) ;re lat ionshipTmp . se tRepet i t i onsCount ( re lat ionshipTmp . getRepet i t ionsCount ( )+

r e l a t i o n s h i p . getRepet i t ionsCount ( ) ) ;}e l s e {

r e l a t i o n sH i s t o r y . add ( r e l a t i o n s h i p ) ;}

}}

}

7.2.9. Código fuente de módulo Relocation

package t e s i s . core . r e l o c a t i o n . impl ;

import java . u t i l . ArrayList ;import java . u t i l . LinkedHashMap ;import java . u t i l . L i s t ;import java . u t i l .Map;import java . u t i l .Map. Entry ;

import org . apache . l o g 4 j . Logger ;

import t e s i s . core . model . f i l e s . Block ;import t e s i s . core . model . f i l e s y s t em . BlockStatus ;import t e s i s . core . model . r e l a t i o n s h i s t o r y t a b l e . Re la t i onsHi s to ryTab le ;import t e s i s . core . model . r e l a t i o n s h i s t o r y t a b l e . Re la t i on sh ip ;import t e s i s . core . r e l o c a t i o n . Re locat ion ;

pub l i c c l a s s Relocat ionImpl implements Re locat ion {

f i n a l s t a t i c Logger LOGGER = Logger . getLogger ( Relocat ionImpl . c l a s s ) ;

pub l i c void execute ( Re la t ionsHi s to ryTab le r e l a t i on sH i s t o ryTab l e ,Map<Long , L i s t<Block>> f i l e s , LinkedHashMap<Block , BlockStatus> sta tusB lock s ) {

LOGGER. debug (" getOpt imalFi lesOrder method") ;L i s t<Long> opt ima lF i l e sOrder = getOpt imalFi lesOrder ( r e l a t i on sH i s t o ryTab l e .

g e tRe l a t i on sh ip s ( ) ) ;

LOGGER. debug (" getOptimalBlocksOrder method") ;L i s t<Block> optimalBlocksOrder = getOptimalBlocksOrder ( opt imalFi l e sOrder , f i l e s ) ;

LOGGER. debug (" r e l o c a t i onB l o ck s method") ;r e l o c a t i onB l o ck s ( optimalBlocksOrder , s t a tu sB lock s ) ;

}

p r i va t e Lis t<Long> getOpt imalFi lesOrder ( Li s t<Relat ionsh ip> r e l a t i o n s h i p s ) {Lis t<Long> opt ima lF i l e sOrder = new ArrayList<Long>() ;

f o r ( Re la t i on sh ip r e l a t i o n s h i p : r e l a t i o n s h i p s ) {i f ( ! opt ima lF i l e sOrder . conta in s ( r e l a t i o n s h i p . g e t F i r s t F i l e I d ( ) ) ) {

opt ima lF i l e sOrder . add ( r e l a t i o n s h i p . g e t F i r s t F i l e I d ( ) ) ;}

i f ( ! opt ima lF i l e sOrder . conta in s ( r e l a t i o n s h i p . ge tSecondFi l e Id ( ) ) ) {opt ima lF i l e sOrder . add ( r e l a t i o n s h i p . ge tSecondFi l e Id ( ) ) ;

}}

re turn opt ima lF i l e sOrder ;}

p r i va t e Lis t<Block> getOptimalBlocksOrder ( Li s t<Long> opt imalFi l e sOrder ,Map<Long , L i s t<Block>> f i l e s ) {

Lis t<Block> optimalBlocksOrder = new ArrayList<Block >() ;

f o r (Long f i l e I d : opt ima lF i l e sOrder ) {LOGGER. debug ("method getOptimalBlocksOrder , f i l e I d "

. concat (Long . valueOf ( f i l e I d ) . t oS t r i ng ( ) ) ) ;



optimalBlocksOrder . addAll ( f i l e s . get ( f i l e I d ) ) ;}

re turn optimalBlocksOrder ;}

p r i va t e void r e l o c a t i onB l o ck s ( Li s t<Block> optimalBlocksOrder ,LinkedHashMap<Block , BlockStatus> sta tusB lock s ) {

i f ( opt imalBlocksOrder . s i z e ( ) == 0) {re turn ;

}

i n t currentBlockIndex = 0 ;Block currentBlock ;

f o r ( Entry<Block , BlockStatus> block : s ta tu sB lock s . entrySet ( ) ) {i f ( b lock . getValue ( ) == BlockStatus .FREE) {

currentBlock = optimalBlocksOrder . get ( currentBlockIndex ) ;

currentBlock . setBlockNumber ( b lock . getKey ( ) . getBlockNumber ( ) ) ;currentBlock . setTrackNumber ( b lock . getKey ( ) . getTrackNumber ( ) ) ;

i f ( opt imalBlocksOrder . s i z e ( ) − 1 == currentBlockIndex ) {re turn ;

}

currentBlockIndex = currentBlockIndex + 1 ;}

}}

}

7.2.10. Código fuente de módulo Orchestrator

package t e s i s . core . o r c h e s t r a t o r . impl ;

import java . u t i l . LinkedHashMap ;import java . u t i l . L i s t ;import java . u t i l .Map;

import org . spr ingframework . beans . f a c t o r y . annotat ion . Required ;

import t e s i s . core . l o c a l i t y p r i n c i p l e . L o c a l i t yP r i n c i p l e ;import t e s i s . core . merge . Merge ;import t e s i s . core . model . f i l e s . Block ;import t e s i s . core . model . f i l e s y s t em . BlockStatus ;import t e s i s . core . model . l o c a l i t y p r i n c i p l e . TemporaryResult ;import t e s i s . core . model . r e l a t i on sh i p s qu eu e . Relat ionshipsQueue ;import t e s i s . core . model . r e l a t i o n s h i s t o r y t a b l e . Re la t i onsHi s to ryTab le ;import t e s i s . core . o r c h e s t r a t o r . Orches t ra tor ;import t e s i s . core . r e l o c a t i o n . Re locat ion ;

pub l i c c l a s s OrchestratorImpl implements Orches t ra tor {

p r i va t e Lo c a l i t yP r i n c i p l e l o c a l i t y P r i n c i p l e ;

p r i va t e Merge merge ;

p r i va t e Re locat ion r e l o c a t i o n ;

pub l i c void execute ( Relat ionshipsQueue re la t ionsh ipsQueue ,Re la t ionsHi s to ryTab le r e l a t i on sH i s t o ryTab l e ,Map<Long , Li s t<Block>> f i l e s ,LinkedHashMap<Block , BlockStatus> sta tusB lock s ) {

TemporaryResult temporaryResult = th i s . l o c a l i t y P r i n c i p l e . execute ( r e l a t i onsh ip sQueue ) ;r e l a t i on sH i s t o r yTab l e . s e tRe l a t i o n sh i p s ( t h i s . merge . execute ( r e l a t i on sH i s t o ryTab l e ,

temporaryResult ) . g e tRe l a t i on sh i p s ( ) ) ;t h i s . r e l o c a t i o n . execute ( r e l a t i on sH i s t o ryTab l e , f i l e s , s t a tu sB lock s ) ;

}



@Requiredpub l i c void s e t L o c a l i t yP r i n c i p l e ( L o c a l i t yP r i n c i p l e l o c a l i t y P r i n c i p l e ) {

t h i s . l o c a l i t y P r i n c i p l e = l o c a l i t y P r i n c i p l e ;}

@Requiredpub l i c void setMerge (Merge merge ) {

t h i s . merge = merge ;}

@Requiredpub l i c void s e tRe l o ca t i on ( Re locat ion r e l o c a t i o n ) {

t h i s . r e l o c a t i o n = r e l o c a t i o n ;}

}

7.2.11. Código fuente de módulo RandomBlockSelector

package t e s i s . core . f i l e s y s t em . r e s o l v e r . s t r a t e g i e s . impl ;

import java . u t i l . L i s t ;import java . u t i l .Random ;

import org . apache . l o g 4 j . Logger ;import org . spr ingframework . u t i l . C o l l e c t i o nU t i l s ;import t e s i s . core . f i l e s y s t em . r e s o l v e r . s t r a t e g i e s . B l o ckSe l e c to r ;import t e s i s . core . f i l e s y s t em . r e s o l v e r . s t r a t e g i e s . model . BlockSe lectorData ;import t e s i s . core . model . f i l e s . Block ;

pub l i c c l a s s RandomBlockSelector implements B lockSe l e c to r {

f i n a l s t a t i c Logger LOGGER = Logger . getLogger ( RandomBlockSelector . c l a s s ) ;

pub l i c Block s e l e c t ( BlockSe lectorData b lockSe l ec to rData ) {List<Block> blocks = blockSe l ec to rData . getBlocks ( ) ;

i f ( C o l l e c t i o nU t i l s . isEmpty ( b locks ) ) {re turn nu l l ;

}

Random randomGenerator = new Random( ) ;

i n t index = randomGenerator . next Int ( b locks . s i z e ( ) ) ;

Block block = blocks . get ( index ) ;

LOGGER. debug ( St r ing . format (" index i s −1 f o r %s " , b lock ) ) ;

r e turn block ;}

}

7.2.12. Código fuente de módulo SecuentialBlockSelector

package t e s i s . core . f i l e s y s t em . r e s o l v e r . s t r a t e g i e s . impl ;

import java . u t i l . L i s t ;

import org . apache . l o g 4 j . Logger ;import org . spr ingframework . u t i l . C o l l e c t i o nU t i l s ;

import t e s i s . core . f i l e s y s t em . r e s o l v e r . s t r a t e g i e s . B l o ckSe l e c to r ;import t e s i s . core . f i l e s y s t em . r e s o l v e r . s t r a t e g i e s . model . BlockSe lectorData ;import t e s i s . core . model . f i l e s . Block ;

pub l i c c l a s s S e cu en t i a lB l o ckSe l e c t o r implements B lockSe l e c to r {

f i n a l s t a t i c Logger LOGGER = Logger . getLogger ( S e cu en t i a lB l o ckSe l e c t o r . c l a s s ) ;



pub l i c Block s e l e c t ( BlockSe lectorData b lockSe l ec to rData ) {Block currentBlock = blockSe l ec to rData . getCurrentBlock ( ) ;L i s t<Block> blocks = blockSe l ec to rData . getBlocks ( ) ;

i f ( C o l l e c t i o nU t i l s . isEmpty ( b locks ) ) {LOGGER. debug (" empty l i s t a ") ;r e turn nu l l ;

}

i f ( currentBlock == nu l l ) {LOGGER. debug (" currentBlock i s nu l l ") ;r e turn b locks . get (0 ) ;

}

i n t index = blocks . indexOf ( currentBlock ) ;

i f ( index == −1){LOGGER. debug ( St r ing . format (" index i s −1 f o r %s " , currentBlock ) ) ;r e turn b locks . get (0 ) ;

}

index = index + 1 ;

i f ( index == blocks . s i z e ( ) ) {//End o f c o l l e c t i o n sLOGGER. debug ( St r ing . format (" l a s t b lock o f c o l l e c t i o n f o r %s " , currentBlock ) ) ;r e turn b locks . get (0 ) ;

}

re turn b locks . get ( index ) ;}

}

7.2.13. Análisis comparativos de los resultados

Para la simulación se utilizó una unidad de almacenamiento con las siguientes características:

1. Formada por 20 pistas.

2. Formada por 1000 bloques por pista.

3. Formada por un total de 20000 bloques disponibles.

Además cada set de procesos se ejecutó 3 veces para obtener una cantidad mayor de valores para analizar.

El set de prueba de archivos se presenta a continuación:

Cantidad de archivos 50 archivos 100 archivos 200 archivos 300 archivos 400 archivosCantidad de bloques utilizados 1353 bloques 2436 bloques 4399 bloques 11162 bloques 8099 bloquesPorcentaje bloques utilizados 6,76 12,18 21,99 55,81 40,49

El set de prueba de procesos se presenta a continuación:



Cantidad de procesos 2500 procesos 5000 procesos 7500 procesos50 archivos accedidos 5476 accesos a archivos.

1358105 bloques accedi-dos.

10884 accesos a archivos.2725149 bloques accedi-dos.


100 archivos accedidos 11583 accesos a archivos.2884391 bloques accedi-dos.












Se generaró un set de datos que represente diferentes cargas de bloques de la unidad de almacenamiento, asícomo diferentes cantidades de procesos que realizan accesos, el �n es obtener resultados para diferentes escenariosy poder analizar los resultados obtenidos.



Ejecución de 2500 procesos:

50 archivos en la unidad de almacenamiento:





[20]



7.2.14. Resumen de los resultados obtenidos

A continuación se exponen tablas que representan las mejoras obtenidas mediante la aplicación de la nueva políticade relaciones basadas en el principio de localidad:


Cantidad de archivos 50 100 200 300 400Máximo tiempo sin la nueva política 754407 1343284 2320207 3320462 4363136Mínimo tiempo sin la nueva política 0 0 34 148 145Máximo tiempo con la nueva política 91718 530552 320076 1702167 497255Mínimo tiempo con la nueva política 0 0 21 78 97Promedio de tiempos sin la nueva política 198658 410071 830637 1245163 1660935Promedio de tiempos con la nueva política 4508 12895 29398 386769 64892





En todos los casos el promedio de los tiempos de acceso se reduce considerablemente, además se observa enlos grá�cos de la sección anterior que la distribución de tiempos de acceso tiende a consolidarse en los valoresmás bajos, cuando sin aplicar el proceso de relaciones por el principio de localidad la distribución de los tiemposestaba dispersa sobre todos los tiempos posibles.


8 CONCLUSIÓN

8. Conclusión

8.1. Análisis de los resultados

En este trabajo se presentó una nueva política para la administración de los bloques pertenecientes a los archivos,la misma se basa en relacionar todos los archivos accedidos por el mismo proceso.

El objetivo de esta nueva política es mejorar los tiempos de acceso, para esto se reubican los bloques de losarchivos respetando el principio de localidad de archivos asociados.

Se efectuó un análisis cualtitativo para analizar el impacto de esta técnica con respecto a la no implementaciónde la misma, los resultados obtenidos arrojaron que la implementación de la misma reduce en gran medida lostiempos de acceso a los archivos.

Quedan planteados trabajos a futuro para mejorar la performance de esta técnica e investigar los campos deaplicación en los que mejores resultados se obtienen, en especial, el estudio de nuevas políticas de reubicación delos bloques (siempre respetando las relaciones de los archivos según la técnica aquí planteada).

Se analizaron varios trabajos de investigación sobre problemas para atacar en los sistemas de archivos, el campode investigación es muy grande.


8 CONCLUSIÓN

8.2. Trabajos futuros

Como trabajos futuros se proponen los siguientes temas:

1. Investigar alternativas para obtener una buena política de reubicación de bloques.

2. Investigar alternativas de mecanismos de log para recuperar la consistencia en el momento de una falla delsistema.

3. Investigar técnicas para controlar la concurrencia en las estructuras que utiliza la técnica planteada.

4. Analizar opciones para el intervalo de ejecución del módulo orquestador.

5. Analizar entornos en los que mejor aplica esta técnica.

La aplicación de una buena técnica de reubicación de bloques es muy importante para incrementar la performancede la técnica, mientras la reubicación se realice de manera más inteligente, menores van a ser los tiempos de acceso.

La concurrencia debe ser investigada para dar respuesta a detalles como el siguiente, qué política tomar cuandose intenta acceder a un archivo que está siendo reubicado?

Un tema muy interesante para abordar es la investigación de los campos especí�cos en los que la aplicaciónde esta técnica incrementa en mayor medida la performance, por ejemplo, servidores dedicados a la ejecución depocos procesos, como un servidor de base de datos, puede tener una mejor performance que una computadorahogareña ya que los pocos procesos acceden a los mismos archivos, en cambio en la computadora hogareña segu-ramente ocurra lo contrario.

La investigación y posterior implementación de estos trabajos futuros van a generar que la técnica sea mássegura y más efectiva. Como se observa, el campo de investigación es muy ámplio.


9 ÍNDICE ALFABÉTICO

9. Índice alfabético

Agrupación por cilindros, 33

Algoritmo de principio de localidad en archivos asociados, 44

Allocate-on-�ush, 37

Asignación de bloques, 8

Bu�er-cache, 38

Bu�ering, 24

Cache, 13

Colas múltiples de reemplazo para el segundo nivel de buer-cache, 41

DataBlocks, 22

Delayed allocation, 33

Desfragmentación, 31

Directorios, 23

Fragmentación, 30

FAT, 17

Hierarquical File System, 26

HPFS, 28

Lectura adelantada de bloques, 13

Lista enlazada de unidades de almacenamiento libres, 11

Mapa de bits, 11

Mecanismo de log para mantener la consistencia en caso de falla, 51

Nodos-i, 10

NTFS, 18

POSIX, 16

preallocate, 37

Principio de localidad, 30

Reducción del movimiento del brazo del disco, 13

Seguridad, 12


9 ÍNDICE ALFABÉTICO

Sistema de archivos, 7

Sistemas de archivos por bitácora, 15

Sistemas de archivos virtuales, 15

Tablas del kernel, 23

Tabla histórica de relaciones, 54

ZFS, 28


10 REFERENCIAS

10. Referencias

[1]Andrew S. Tanenbaum. Sistemas operativos modernos.

[2]Apuntes de la materia organización de datos.

[3]http://www.tldp.org/HOWTO/Filesystems-HOWTO-7.html#hfs

[4]http://developer.apple.com/legacy/mac/library/documentation/mac/MoreToolbox/MoreToolbox-11.html

[5]http://pages.cs.wisc.edu/~legault/miniproj-736.pdf

[6]http://kernelnewbies.org/Ext4#head-38e6ac2b5f58f10989d72386e6f9cc2ef7217fb0

[7]http://www.ibm.com/developerworks/linux/library/l-ext4/

[8]http://hub.opensolaris.org/bin/view/Community+Group+zfs/docs

[9]http://www.ibm.com/developerworks/linux/library/l-anatomy-ext4/

[10]http://technet.microsoft.com/en-us/library/cc778290(WS.10).aspx

[11]�Johns Hopkings university�, Ext3cow: A Time-Shifting File System for Regulatory Compliancehttp://hssl.cs.jhu.edu/~zachary/papers/peterson-tos05.pdf

[12]�A Fast File System for UNIX, university of California�http://www.cs.berkeley.edu/~brewer/cs262/FFS.pdf

[13]"Intelligent methods for �le system optimization, Leo Kuvayev university of Massachusetts"http://clgiles.ist.psu.edu/papers/AAAI-97.intelligent.�le.organization.pdf

[14]"Ext4, btrfs, and the others, Jan Kára"http://atrey.karlin.m�.cuni.cz/~jack/papers/lk2009-ext4-btrfs.pdf

[15]"The new ext4 �lesystem: current status and future plans, IBM Linux Technology Center"http://kernel.org/doc/ols/2007/ols2007v2-pages-21-34.pdf

[16]�The e�ects of age and fragmentation on �le system performance, Harvard university�http://www.eecs.harvard.edu/~keith/research/tr94.html

[17]�Design algorithms for asynchronous write operations in disk-bu�er-cache memory, AT&T Bell Laborato-ries, Naperville, Illinois, USA�

[18]�A Better Update Policy, Je�rey C. Mogul, Digital Equipment Corporation Western Research Laboratory�

[19]�The MultiQueue replacement algorithm for second level bu�er caches, Yuanyuan Zhou and James F. Philbin,Princeton university�

[20]�Average seek time of a computer disk�, Computer Science Department, SUNY/Plattsburgh,http://faculty.plattsburgh.edu/jan.plaza/teaching/papers/seektime.html

[21]�File Structures�, Zoellick y Folk


Tesis de grado de Ingeniería en informáticamaterias.fi.uba.ar/7500/TesisLeguizamo.pdf · Tesis de...

Documents

Transcript of Tesis de grado de Ingeniería en informáticamaterias.fi.uba.ar/7500/TesisLeguizamo.pdf · Tesis de...