Sistemas de Archivos: Propuesta para optimizar el rendimiento mediante la localidad de archivos asociados

UNIVERSIDADNACIONALDEPIURA FACULTADDEINGENIERAINDUSTRIAL ESCUELAPROFESIONALDEINGENIERAINFORMTICA
Sistemas de Ar chivos, Tendencias y mejoras tecnolgicas Presentada por: Alvarado Pulido Domingo Fernando Castro Hurtado Arnaldo Flores Pea Cristian Sosa Olaya Xiomara Mercedes TESIS PARA OPTAR EL TTULO DE: Ingeniero Informtico Piura, Per 2012
NDICE
ndice
1. Resumen 2. Introduccin 3. Introduccin 4. Rele vamie nto bibliogr fi co sobre sistemas de archivos 4.1. Asignacin de bloques a archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1. Asignacin contigua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2. Asignacin por lista enlazada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3. Asignacin por lista enlazada utilizando una tabla en memoria . . . . . . . . . . . . 4.1.4. Nodos-i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Administracin de espacio libre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1. Administracin media nte mapa de bits. . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2. Administracin media nte lista enlazada de unidades de almacenamie nto libres. . . . 4.3. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. Rendimie nto del sistema de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1. Uso de cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2. Lectura adela ntada de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3. Reduccin del movimiento del brazo del disco. . . . . . . . . . . . . . . . . . . . . . 4.5. Impleme ntacin de directorios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Nuevas prestaciones en sistemas de archivos. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1. Sistemas de archivos estructurados por registro . . . . . . . . . . . . . . . . . . . . . 4.6.2. Sistemas de archivos por bitcora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3. Sistemas de archivos virtuales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7. Casos de estudio de sistemas de archivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1. DOS (Disk Operating System) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.2. NTFS (New Technology File System) . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.3. UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.4. EXT-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.5. EXT-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.6. EXT-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.7. HFS (Hierarquical File System) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.8. HFS+ (HFS plus) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.9. HPFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.10. ZFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 7 7 8 9 9 10 10 10 11 12 12 12 13 14 14 14 15 15 17 20 23 25 25 25 27 27 27 4 5
5. Rele vam nto bibliogrfico ie de mt odos y tendencias para optim izar el rendimie nto de sistem as de archivo 29 5.1. Fragme ntacin en sistemas de archivos y Principio de localidad . . . . . . . . . . . . . . . . . . . . 29 5.1.1. Fragme ntacin de archivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.1.2. Principio de localidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2. Desfragme ntacin y tcnicas para reducir la fragme ntacin en sistemas de archivos actuales . . . . 30 5.2.1. Sistemas de archivos Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2.2. Sistemas de archivos archivos Unix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2.3. Sistema de archivos EXT-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.2.4. Sistema de archivos EXT-4, HFS+, ZFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.2.5. Ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.3. Lneas de investigacin sobre tcnicas para evitar la fragme ntacin en sistemas de archivos modernos 32 5.3.1. Sistemas de archivos Unix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.3.2. Sistemas de archivos NTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.3.3. EXT-4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.4. Buffer-ca che para la optimizacin de tiempos de acceso. . . . . . . . . . . . . . . . . . . . . . . . . 36 5.4.1. Buffer-ca che. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.4.2. Poltica de remplazo de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
NDICE
5.4.3. Sincronizacin para el remplazo de bloques. . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.4.4. Optimizacin en la performance del buffer-ca che por medio de algoritmos que utilizan informacin de la carga del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.4.5. Optimizacin en la performance del buffer-ca che por medio de mejoras en la poltica de actualizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.4.6. Colas mltiples de remplazo para el segundo nivel de buffer-ca che. . . . . . . . . . . . . . 40 6. Ela boracin de una propuesta de solucin alternati va o superadora 43 6.1. Localidad de archivos asociados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.1.1. Algoritmo de principio de localidad en archivos asociados . . . . . . . . . . . . . . . . . . . 43 6.1.2. Heurstica para el algoritmo de principio de localidad en archivos asociados . . . . . . . . . 45 6.1.3. Mtodo para evitar la fragme ntacin en archivos asociados . . . . . . . . . . . . . . . . . . 45 6.1.4. Resultado de la reubicacin de archivos segn las relaciones. . . . . . . . . . . . . . . . . . 45 6.2. Persistencia temporal de los accesos a archivos por los procesos. . . . . . . . . . . . . . . . . . . . 45 6.3. Depuracin de la tabla histrica de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.4. Mdulos que forman la solucin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.4.1. Mdulo que impleme nta el algoritmo del principio de localidad en archivos asociados. . . . 48 6.4.2. Mdulo de merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.4.3. Mdulo de reubicacin de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.4.4. Mdulo orquestador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.4.5. Heurstica para la ejecucin del mdulo de orquestacin. . . . . . . . . . . . . . . . . . . . 49 6.4.6. Mecanismo de log para mantener la consistencia en caso de falla . . . . . . . . . . . . . . . 50 6.4.7. Control de la concurrencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.4.8. Mdulo de rol back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.4.9. Mdulo de depuracin de la tabla histrica de relaciones. . . . . . . . . . . . . . . . . . . . 51 6.4.10. Frecuencia de ejecucin del mdulo orquestador . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.5. Modif i caciones necesarias en Sistema de archivos NTFS para soportar esta tcnica . . . . . . . . . 52 6.5.1. Cola compartida de relaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.5.2. Tabla histrica de relaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.5.3. Estructura utilizada para identif i cacin de inconsistencias tras una falla . . . . . . . . . . . 53 6.5.4. Estructura utilizada para por el proceso de rol back . . . . . . . . . . . . . . . . . . . . . . 54 6.5.5. Modif i caciones generales en los Sistemas de archivos . . . . . . . . . . . . . . . . . . . . . . 55 7. Evaluacin Analtica y Ex perime ntal de la Propuesta 56 7.1. Evaluacin analtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 7.1.1. Hiptesis sobre el tiempo de seek. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 7.1.2. Hiptesis sobre el tiempo de latencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 7.1.3. Hiptesis sobre el tiempo de transferencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.1.4. Expresin general del tiempo de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.1.5. Grfico del tiempo de seek en funcin de la distancia entre cilindros . . . . . . . . . . . . . 57 7.1.6. Grfico del tiempo de latencia en funcin de la distancia entre bloques. . . . . . . . . . . . 58 7.1.7. Observaciones f i nales sobre el tiempo de acceso. . . . . . . . . . . . . . . . . . . . . . . . . 59 7.2. Evaluacin Experime ntal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.2.1. Descripcin de la simulacin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.2.2. Diagrama de arquitectura de la simulacin. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.2.3. Diagrama de secuencia de la simulacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.2.4. Cdigo fuente de mdulo FileSystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.2.5. Cdigo fuente de mdulo TimesHelper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.2.6. Cdigo fuente de mdulo LocalityPrinciple . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.2.7. Cdigo fuente de mdulo CartesianPr oductHel per . . . . . . . . . . . . . . . . . . . . . . . 66 7.2.8. Cdigo fuente de mdulo Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.2.9. Cdigo fuente de mdulo Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.2.10. Cdigo fuente de mdulo Orchestrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.2.11. Cdigo fuente de mdulo RandomBl ockSelector . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.2.12. Cdigo fuente de mdulo SecuentialBlockSelector . . . . . . . . . . . . . . . . . . . . . . . . 70 7.2.13. Anlisis comparati vos de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 7.2.14. Resumen de los resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 2
NDICE
8. Conclusiones 88 8.1. Anlisis de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 8.2. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 9. Referencias Bibliogrficas 90
1 RESUMEN
1.
Resumen
El presente proyecto de tesis consiste en los Sistemas de Archivos, Tendencias y mejoras tecnolgicas, el cual est basado en analizar tendencias y puntos dbiles de sistemas de archivos para plantear mejoras a alguno de estos aspectos; para esto, el trabajo se divide en cuatro etapas. La primera etapa est dedicada a un relevamiento bibliogrfico y la confeccin de un informe sobre Sistemas de Archivo. La segunda etapa se centra en un relevamiento bibliogrfico y con la confeccin de un informe sobre tendencias tecnolgicas para optimizar el rendimiento de los sistemas de archivo. En la tercera se elaborar el planteo de una propuesta de solucin alternativa, superadora o complementaria para atacar los problemas detectados. La cuarta etapa consiste en la evaluacin analtica y/o experimental de la propuesta. Una vez completadas todas las etapas, esto ser sometido a pruebas y validaciones para determinar el correcto funcionamiento del sistema y que realice de manera adecuada las funciones que se esperan de l.
2. INTRODUCCIN
2.
Introduccin
La mayora de los sistemas de software requieren almacenar y recuperar informacin de dispositivos de alma cenamiento masivo para cumplir sus objetivos. Determinado tipo de informacin requiere ser accedida por varios procesos (aplicaciones que estn en ejecucin) en paralelo, es decir, se debe poder acceder de manera concurre nte. La forma de almacenar la informacin es media nte archivos; stos son unidades lgicas de almacenamie nto de informacin, y los sistemas de software o aplicaciones son los que deben saber interpretar los datos para transfor- marlos en informacin. El tamao mnimo que puede tener un archivo es el tamao de un bloque, esto se debe a que un bloque es la unidad mnima de almacenamie nto. 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 administracin de los archivos se conoce como sistema de archi vos, que es el tema de la tesis.
4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS
4. Rele vamie nto bibliogrfic o ar chi vos

4.1. Asignacin de bloques a ar chivos
sobre
sistemas
de
Los archivos se almacenan en bloques, y el conjunto de bloques asignados a un archivo contiene la totalidad de la informacin almacenada en l. Para recuperar todo el archivo se debe tener algn mecanismo para referenciar a todos estos bloques. A continuacin se hace una descripcin de disti ntas opciones. 4.1.1. Asignacin contigua
Este es el mecanismo ms 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 tendra 10 bloques seguidos. En la imagen 4.1 se visualiza un ejemplo de tres archivos y con bloques libres a continuacin de los del archivo C.
Este mtodo tiene dos grandes virtudes, la primera es que es de fcil impleme ntacin ya que los datos necesarios para la impleme ntacin son el nmero del primer bloque y la cantidad de los mismos. La otra virtud que tiene este mtodo es que la recuperacin del archivo completo se puede realizar con el mnimo tiem po de seek posible (tiem po de posicionamie nto de un bl oque para ser ledo) ya que los bloques son contiguos. Por lo tanto este mtodo tiene las ventajas de ser de fcil impleme ntacin y adems tiene alto rendimie nto; pero en contraposicin 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 fragme ntacin (tambin se puede dar cuando se actualiza un archivo de manera que cambie su tamao). Este efecto se puede visualizar en la imagen 4.2.
Con el paso del tiempo esta fragme ntacin se vuelve problemtica porque en algn momento la unidad de alma cenamiento se puede llenar y entonces se deben reutilizar los bloques que fueron liberados con anterioridad. Para esto se debe calcular el tamao del archivo a crear y recorrer todos los huecos hasta enco ntrar uno tal que su tamao sea mayor o igual que el de el archivo que se desea almacenar [1]. 4.1.2. Asignacin por lista enlazada
Esta varia nte se caracteriza por mantener los bloques de los archivos enlazados media nte referencias de manera que constitu yan una lista. Se utilizan algunos bytes de cada bloque para apu ntar al siguiente. Con este mtodo no se pierde espacio por fragme ntacin (excepto por la fragme ntacin interna del ltimo bloque de cada archivo); adems, para la entrada al directorio slo se necesita la direccin del primer bloque porque por las referencias internas se obtiene siempre el siguiente. Una contra que tiene este mtodo es que para llegar al bloque n de un archivo se necesita leer sus n-1 bloques previos, lo cual no es para nada e ciente. En la imagen 4.3 se ejemplifi ca una lista enlazada de bloques para un archivo llamado A. [1]
4.1.3.
Asignacin
por lista enlazada
utilizando
una tabla en memoria
Una manera de eliminar las desventajas del mtodo de lista enlazada es tener los apuntadores de los bloques siguientes en una tabla externa a los bloques que est en memoria. En la imagen 4.4 se observa la tabla en cuestin para el archivo A utilizado en el mtodo anterior.
La tabla en cuestin es la llamada FAT (File Allocation Table); para recorrer un archivo basta con seguir la secuencia de referencias hasta que se termine. Esta tcnica tiene las ventajas de utilizar todo el espacio de los bloques para datos y de no tener que acceder a disco para obtener la referencia del siguiente bloque, ya que la tabla, aunque persistida en disco, se maneja en memoria; esto hace que el acceso a todos los bloques del archivo sea ms rpido que en el mtodo anterior. La principal desventaja es que toda la tabla debe estar en memoria todo el tiempo para que funcione, para discos muy grandes y tamaos de bloques pequeos se necesitan muchas entradas y eso hace que el tamao crezca demasiado. Por lo tanto esta tcnica es inef i ciente en discos muy grandes. [1] 4.1.4. Nodos-i
Este mtodo se caracteriza por tener una estructura llamada i-node (index node) que contiene los atributos y la lista de los bloques del archivo; por lo tanto para acceder a todos los bloques del archivo se debe acceder a su i-node. El i-node slo debe estar en memoria cuando est abierto el archivo; esta es una gran ventaja sobre el mt odo de la FAT, que tiene toda la tabla en memoria. El principal problema de este mtodo es que los i-nodes son de tamao , por lo cual se puede direccionar una cantidad determinada de bloques, y a veces esta cantidad de bloques puede ser menor que la que tiene el archivo en cuestin. Una manera de solucionar este problema es reservar el ltimo elemento de la lista de direccionamie nto para direccionar un bloque que contiene direcciones de bloques y no datos. En la imagen 4.5 se visualiza la estructura de un i-node. [1]
4.2.
Administracin
de espacio libre
Cuando un archivo increme nta su tamao o se crea, es necesario obtener unidades de almacenamie nto libres para insertar los datos. La administracin del espacio libre se puede realizar media nte un mapa de bits o una lista enlazada de unidades de almacenamie nto libre s. 4.2.1. Administracin media nte mapa de bits
Un mapa de bits es una estructura que asigna un bit de estado a cada unidad de almacenamie nto (por ejemplo bloques), indicando si est libre o no. Una desventaja de este mtodo es que se debe tener la informacin de todas las unidades de almacenamie nto en la estructura. Una ventaja es que se accede de manera directa y no se debe realizar un recorrido secuencial hasta ubicar el estado de la unidad en cuestin porque basta con su nmero para acceder al nodo del mapa y veri car si est libre o 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 secuencialme nte toda la estructura hasta obtener los bloques que cubran el espacio libre requerido. La imagen 4.6 ejempli ca este mtodo. [1]
4.2.2.
Administracin
media nte lista enlazada
de unidades
de almacenamie
nto libres
Una lista enlazada es una estructura que tiene una referencia al siguiente nodo y al anterior. Cada uno de los nodos de la lista contiene informacin de una unidad de almacenamie nto (por ejemplo un bloque). Al ser una lista de bloques libres, slo tiene la informacin de aquellos que estn libres, por lo cual, cuando se necesita espacio para un archivo, se recorre la lista hasta obtener el espacio requerido y se quita de la lista los nodos de los bloques obtenidos. La imagen 4.7 ejempli ca este mtodo. [1]
4.3.
Seguridad
Los permisos sobre los archivos o sobre los directorios permiten el acceso a determinados usuarios o a grupos de usuarios, estos permisos se guardan en estructuras que varan dependiendo el sistema de archivos. Estos permisos se re eren a permisos de lectura, escritura y ejecucin del archivo. Sobre un directorio estos permisos re eren bsicame nte a las operaciones de lectura, escritura y ejecucin sobre los archivos que contiene. [2]
4.4.
Rendimie nto del sistema de archivos
El acceso a disco es mucho ms lento que el acceso a memoria. Para leer una palabra de memoria de 32bits se podran requerir 10 nseg. La lectura de un disco rgido se podra realizar a 100MB/seg, que es cuatro veces ms lenta que la palabra de 32bits, pero a esto se le debe agregar de 5 a 10 mseg para realizar una bsqueda hasta la pista y despus esperar a que se coloque el sector deseado bajo el cabezal de lectura. Si se necesita slo una palabra, el acceso a memoria est en el orden de un milln de veces ms rpido que el acceso a disco. 10
Como resultado de esta diferencia en el tiempo de acceso, muchos sistemas de archivos se han diseado con varias optimizaciones para mejorar el rendimie nto. 4.4.1. Uso de cache
Un cach es una coleccin de bloques que pertenecen lgicamente al disco pero que estn en memoria para mejorar el rendimie nto del sistema de archivos. Para administrar la memoria cach se analizan todos los pedidos de bloques, y si el bloque est en la cache se devuelve, en caso contrario se accede a la unidad de almacenamie nto para 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 rpida, para esto se utiliza una tabla hash a la cual se accede media nte un cdigo hash que se obtiene con la direccin de dispositivo. Todos los bloques con el mismo valor de hash se encadenan en una lista enlazada de 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 y guardarlo en la unidad de almacenamie nto, para la seleccin de dicho bloque se utilizan algoritmos como LRU (menos recie nteme nte utilizado), FI FO (cola), etctera. [1] 4.4.2. Lectura adela ntada de bloques
Esta tcnica se basa en tratar de colocar bloques en la cach antes de que se necesiten, de esta manera se incrementa la tasa de aciertos en la cach. Cuando se solicita al sistema de archivos el bloque n de un archivo, adems se realiza la verif i cacin para ver si el bloque n+1 est en la cach; si no est, se carga con el propsito de que cuando sea solicitado est cargado o al menos est en curso. Esta tcnica funciona para archivos secuenciales, en archivos de acceso aleatorio perjudica el funcionamie nto, para evitar esto se verifica el modo de acceso al archivo para determinar si se trata de un acceso secuencial o aleatorio. Este mtodo funciona bajo el concepto de localizacin de los datos, que platea que si se necesita un bloque en muy probable que se necesite el siguiente en el corto plazo. [1] 4.4.3. Reduccin del movimie nto del brazo del disco
Esta tcnica se basa en colocar los bloque que tengan probabilidad de utilizarse en secuencia uno a continuacin del otro, prefere nteme nte en el mismo cilindro. Cuando se realiza la creacin o incremento del tamao de un archivo se debe realizar un anlisis para ubicar todos los bloques lo ms cerca posible. De esta manera se reduce el movimiento del brazo del disco, con lo cual se reducen los tiempos de acceso y la performance crece. [1]
4.5.
Impleme ntacin de directorios
Para poder utilizar un archivo primero debe ser abierto, para esto el sistema operativo utiliza el nombre del archivo en cuestin para localizar la entrada del directorio. Esta entrada provee la informacin necesaria para enco ntrar todos los bloques del archivo. Por lo tanto la funcin principal de un sistema de directorios es realizar la asociacin del nombre del archivo y la informacin necesaria para obtener todos sus datos. Una cuestin muy relacionada es en dnde se guardan los atributos de los archivos. Una opcin es guardar estos atributos en el mismo directorio, de esta manera los directorios son una lista de nombres de archivo, atributos y bloques de dicho archivo. Este mtodo se ejemplifi ca en la imagen 4.8.
11
Otra tcnica es guardar los atributos en i-nodos, de esta manera el directorio es una lista de nombres de archivo ms un nmero de i-nodo en el que se encue ntra la informacin del archivo como atributos, i-nodo, etc. Este mtodo se ejempli ca en la imagen 4.9.
Otro tema importa nte para tratar es la impleme ntacin de los nombres de los archivos: algunas impleme ntaciones soportan archivos con 8 caracteres de nombre ms 3 de extensin, otras soportan 14 caracteres, sin embargo los sistemas operativos modernos soportan nombres de archivo largos; a continuacin se detallan algunas maneras de impleme ntarlo. Una posible impleme ntacin es reservar 255 caracteres para el nombre de cada archivo que exista, el problema con esto es que se desperdicia mucho espacio debido a que el nombre puede tener menos de 255 caracteres. Otro mtodo es tener un encabezado por archivo que contenga determinados datos como por ejemplo la longitud del nombre y a continuacin est el nombre del archivo, de esta manera no se desperdicia espacio. Un problema que tiene este mtodo es que cuando se borra algn archivo queda un hueco de longitud variable. Otra alternati va es tener un encabezado en el directorio en el que se encuentre la referencia al nombre del archivo y atributos; el nombre del archivo se ubica en otro sector del directorio reservado para almacenar todos los nombres de los archivos. En lo que respecta a bsquedas de un archivo dentro de un directorio, se usan tres mtodos que se describen a continuacin. El primer mtodo es realizar una bsqueda secuencial hasta enco ntrar el archivo que se est buscando; esto puede llegar a ser muy costoso en el caso que se tenga muchos archivos en el directorio. Una alternati va al mtodo anterior es tener una tabla hash para cada directorio en la cual la clave es el nombre del archivo, este mtodo es mucho ms ef i cie nte que el anterior pero le gana en complejidad. Una mejora del primer mtodo es tener una cach para los nombres de los archivos: antes de realizar la bsqueda se verifica en la cache si est el nombre del archivo, y en el caso de que no est se realiza la bsqueda dentro del directorio y al resultado se lo ubica en la cache. [1]
4.6.
Nue vas prestaciones
en sistemas de archivos
Con el avance de los sistemas de archivos fueron surgiendo nuevos tipos que resuelven los problemas antes planteados y agregan nuevas prestaciones. Algunas de estas nuevas prestaciones son utilizar la cache de disco de una manera ms efecti va, gara ntizar la integridad (recu peracin de fallos) y proveer una interfaz virtual para trab ajar con disti ntas impleme ntaciones de sistemas de archivos.
12
4.6.1.
Sistemas
de ar chi vos estructurados
por registro
El tipo de sistemas de archivos estructurado por registro naci como consecuencia del incremento de la velocidad de las CPU, del incremento en el tamao de las memorias RAM y del incremento en el tamao de las cache de disco. En consecuencia es posible satisfacer gran parte de las lecturas a disco desde la cache sin tener que acceder al disco . La idea es estructurar todo el disco como un registro. Todas las escrituras a disco son colocadas en un buffer en memoria, y peridicame nte todas las pendientes se escriben en el disco (al final del registro) como si fuera un solo segmento. Para que este mecanismo funcione cada segmento debe tener toda la informacin administrati va necesaria de las estructuras que contiene ya que puede contener i-n odos (en el caso de Unix), bl oques de directorios, bloques de archivos, etc.[1] Este mtodo se ejemplifi 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 ejemplo el espacio que estaba asignado a un archivo que fue borrado. Peridicame nte se recorre el registro de manera cclica comenzando por el primer segme nto y analizando la informacin que contiene para liberar los bloques que ya no son utilizados. 4.6.2. Sistemas de ar chi vos por bitcora
La idea de este sistema de archivos es ma ntener un registro de lo que se va a hacer antes de hacerlo, por lo tanto si el sistema falla antes de realizar alguna tarea, cuando se reinicia el sistema puede buscar en el registro lo que se iba a realizar y completar dicha tarea. Para que un sistema de archivos por bitcora funcione las operaciones que realiza deben ser idempotentes, lo cual significa que puede repetirse todas las veces que sea necesario sin peligro alguno. Adems, para ofrecer mayor seguridad se puede utilizar el concepto de base de datos llamado transacciones, de esta manera el sistema de archivos agrupa operaciones a realizar y sabe que deben ejecutarse sin problema todas o ninguna. [1] 4.6.3. Sistemas de ar chi vos virtuales
A menudo en una computadora hay ms de un sistema de archivos instalado, los sistemas operativos controlan este aspecto de determinadas maneras, lo que se busca con un sistema de ar chi vos virtual (VFS) es integrar diferentes sistemas de archivos en una unidad ordenada. La idea principal (y clave) es poner todo lo que es compartido por todos los sistemas de archivos en una capa separada que llame a los sistemas de archivos concretos subyacentes para administrar los datos. Todas las llamadas al sistema relacionadas con archivos se dirigen al sistema de archivos virtual para su procesamiento inicial. Estas llamadas, que provienen de procesos de usuarios, son las llamadas estndar como open, 13
read, write, lseek, etctera. Por lo tanto, el VFS tiene una interfaz superior para los procesos de usuarios y es la interfaz llamada POSIX . El VFS tambin tiene una interfaz inferior para los sistemas de archivos concretos, esta interfaz consiste de llamadas a funciones que el VFS puede hacer a cada sistema de archivos para realizar su trab ajo. Por lo tanto para que un sistema de archivos trab aje con el VFS basta con que suministre las llamadas a las funciones que realiza 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 tcnicas para los aspectos antes descriptos, en esta seccin se ejemplifi carn varios sistemas de archivos describiendo sus principales estructuras para la administracin de los archivos as como los mtodos utilizados por cada uno. 4.7.1. DOS (Disk Operating System)
Las unidades de almacenamie nto son los llamados clusters , estos son conjuntos de sectores del disco (cada sector tiene 512 bytes) que dependiendo de determinados parmetros (como el tamao del disco) pueden ser: dos, cuatro, ocho, etctera 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 contiene los datos del archivo al que referencia, la estructura de estos registros se observa en la imagen 4.12
14
Como se puede apreciar el nombre de los archivos puede tener hasta ocho caracteres y tres de extensin, esta informacin se almacena en los ocho primeros bytes de cada registro. El byte destinado a los atributos especfica si es un archivo de sistema, de slo lectura, si est oculto, si es un subdirectorio, etctera. Los bytes 21 al 25 contienen la fecha y hora de creacin o de ltima Modif i cacin del archivo, la hora se divide en segundos (5 bits), minutos (6 bits) y horas (5 bits). La fecha se cuenta en das usando tres subcampos: da (5 bits), mes (4 bits) y ao desde 1980 (7 bits). El nmero del primer bloque del archivo se encue ntra en el byte 25 y tiene una longitud de dos bytes. Adems se almacena el tamao del archivo en los ltimos cuatro bytes del registro, por lo tanto en teora un archivo podra ocupar hasta 4 GBytes, aunque por motivos que se analizarn a continuacin el tamao mximo de un archivo es de 2 GBytes o menos. La cuenta de los clusters se lleva a travs de una tabla de asignacin de archivos (FAT) en la memoria principal. Dado que cada registro de directorio tiene el nmero del primer cluster del archivo se puede acceder a la tabla y navegarla para obtener todos los clusters del archivo. En la imagen 4.4 se observa la tabla en cuestin. La tabla en cuestin puede ser FAT-12, FAT-16 o FAT-32, dependiendo de la cantidad de bits que tenga cada direccin de disco. FAT-12 proporciona un tamao mximo de particin igual a 4096 x 512 Bytes (en realidad 4086 x 512 Bytes debido a que 10 de las direcciones del disco se utilizan para otras cuestiones como n de archivo, cluster defectuoso, etc.) que da aproximadame nte un tamao mximo por particin de 2 MB, el tamao de la FAT en memoria es de 4096 entradas con 2 Bytes cada una. FAT-16 tiene 16 bits para direccionar lo cual increme nta el tamao mximo por particin a un mximo de 2 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 tamao mximo por particin est acotado a 2 TBytes debido a que el sistema lleva de manera interna la cuenta de los tamaos de las particiones utilizando un nmero de 32 bits. Dado que un archivo requiere como mnimo un cluster para su almacenamie nto una gran ventaja de FAT-32 es que se desperdicia poco espacio en comparacin a las dems FAT, esto se debe a que permite tamao de clusters ms pequeos que las dems FAT, por lo tanto al almacenar un archivo que ocupe menos espacio que un cluster se desperdicia el espacio que le queda libre al cluster que es menos que en la dems FAT. DOS utiliza la FAT para llevar la cuenta de los clusters libres en el disco. Cualquier cluster que est libre se marca con un cdigo especial, y cuando se necesita un cluster libre se lo busca en la FAT. De esta manera se evita la utilizacin de un mapa de bits o de una lista enlazada para clusters libres. [1] [2] 15
4.7.2. System)
NTFS
(New
Technology
File
Estructura del sistema de archivos: Cada particin de disco (volumen) de NTFS contiene archivos, directorios, mapa de bits y otras estructuras de datos. Cada particin se organiza en una secuencia de clusters, el tamao de estos est jo y vara de acuerdo al tamao de la particin. Para hacer referencias a los clusters se utiliza su o set desde el inicio de la particin media nte un nmero de 64 bits. La estructura principal es la llamada M FT( Tabla m aestra de ar chi vos), esta es una secuencia de registros de un 1KB de tamao, donde cada registro describe un archivo o directorio, es decir, contiene los atributos como su nombre, una lista de direcciones en el disco en donde se encue ntran sus clusters, etc. En el caso de que un archivo sea muy grande se usa ms de un registro para direccionar a todos los clusters de dicho archivo, con lo cual el primer registro de la MFT llamado registro base direcciona a los otros registros. Un mapa de bits controla las entradas 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 (enca bezado de atributo- valor). Cada atributo comienza con un encabezado que indica qu tipo de atributo es, y cul es el largo del valor. Algunos valores de atributos son de longitud variable como es el nombre del archivo y los datos. Si el valor del atributo es lo su cienteme nte corto como para caber en el registro se deja all, en caso contrario se almacena en algn lugar de la unidad de almacenamie nto y se almacena su ubicacin en el valor del par atributo- valor en cuestin.
16
Los primeros 16 registros de la MFT se reservan para archivos de metadatos como se observa en la imagen 4.13. El primer registro est destinado a la ubicacin de los clusters de la MFT; pero es necesario conocer la ubicacin del primer cluster de la MFT para poder acceder a ella y as conocer la ubicacin de los dems, para esto se debe acceder al bloque de inicio de la particin (volumen) que entre otros datos contiene la direccin del cluster en cuestin. NTFS de ne 13 atributos que pueden aparecer en los registros de la MFT, esto se muestran en la imagen 4.14.
El campo informacin estndar contiene la informacin del propietario, informacin de seguridad, la cantidad de enlaces duros, los bits de slo lectura, etc. Es un campo de longitud f i ja. El campo nombre de archivo contiene el no mbre del ar chi vo en Unicode y es de longitud variable. El campo descriptor de seguridad slo se utiliza en NT 4.0 ya que en los siguientes sistemas operati vos se 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 indica en dnde ubicar los registros de extensin. El campo ID de objeto se utiliza para acceder a los archivos. El campo pu nto de re anlisis indica en nombre del procedimie nto que se utiliza para montar sistemas de archivos de manera explcita y para los vnculos simblicos. Los campos de volumen se utilizan para identificar el volumen. Los campos raz de ndice, asignacin de ndice y mapa de bits se relacionan con la manera en que se impleme ntan los directorios, los pequeos son listas de archivos, y los grandes son rboles B+. El campo flujo de utilera con registro es usado por el sistema de archivos de cifrado.
El campo datos represe nta los datos del archivo, en el caso que los datos sean pocos se ubican en este atributo (archivo inmediato), en caso contrario represe nta las direcciones de los clusters del archivo. [1]
17
Asignacin de los clusters para el almacenamie nto: 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 media nte un registro. Esto ser analizado en detalle en la seccin de rele vam nto bibliogrfico ie y tendencias tecnolgica s. Compresin de archivos: NTFS proporciona compresin para los archivos, se pueden crear archivos en modo comprimido, por lo tanto NTFS trata de comprimirlos a medida que se escriben sus datos en el disco y los descomprime cuando se leen. La compresin se basa en aplicarle un algoritmo de compresin a los primeros 16 clusters del archivo y si consigue comprimirlos se guardan de manera comprimida, en el caso de que no se puedan comprimir los datos se guardan sin comprimi r. 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 compresin se aplica ms all de si los clusters se ubican en secuencia consecutiva 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 partes se han escrito como tres secuencias de clusters consecutivos y se han almacenado en el registro de la MFT. Los clusters falta ntes se han almacenado en la MFT con la direccin 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 (comprimido), uno para el conjunto descomprimido y dos para el conjunto f i nal (comprimido).
18
Cuando el archivo se vuelve a leer, NTFS debe saber cules con los conjuntos de clusters que estn comprimidos y cules no, para esto se analiza la direccin de disco inicial de cada uno que est en su par (direccin inicial cantidad de clusters) corres pondie nte, si la direccin inicial es 0 indica que es parte f i 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 particin no se puede utilizar para almacenar datos. [1] Registro de transacciones: NTFS proporciona dos mecanismos de registro de transacciones, el primero se basa en una operacin de E/S llamada NtNotifyChangeDirectoryFile, que se basa en una llamada CallBack que recibe un buffer del sistema, este buffer se llena con datos de cambios en directorios y archivos, es decir, con el registro de los cambios de la particin. El otro mecanismo se basa en persistir todos los cambios de la particin en un archivo que puede ser consultado media nte llamadas a la API de NtfsCo ntrolFile, esta funcin es la llamada FSCTL_QUE RY_USN_JOURNAL. [1] 4.7.3. UNIX
En Unix, el sistema de archivos es uno de los componentes del kernel. Los procesos interactan con el sistema de archivos a travs de las system calls que a su vez pueden hacer llamadas a funciones de ms bajo nivel del sistema de archivos. El sistema de archivos interacta con los dispositivos a travs de los drivers especf i cos de cada uno. En el caso de que los dispositivos son orientados a bloques, existe un nivel de buf f ering entre el sistema de archivos y los dispositivos. Esto se puede observar en la imagen 4.16. Cabe mencionar que la unidad mnima de almacenamie nto en UNIX se denomina bloque y no un cluster como en NTFS. [2]
I-Nodos:
19
La estructura principal para la administracin de los archivos es el i-n odo, esta estructura es de tamao y contiene la siguiente informacin:
jo
Identif i cacin del creador del archivo. Tipo de archivo, esto es por ejemplo, normal, directorio, etc. Este campo suele utilizarse adems para indicar si el i-node est libre. Permisos de acceso, cada archivo admite tres tipos de permisos, lectura, escritura y ejecucin. Cada uno de estos permisos puede ser negado de manera independie nte al dueo del archivo, a su grupo y al resto de los usuarios. Fecha de la ltima modif i cacin del archivo, ltimo acceso al mismo, ltima fecha de modi cacin del inodo, etc. Nmero de links al archivo, el i-nodo de cada archivo es nico, sin embargo, el archivo puede ser referenciado desde diferentes directorios bajo disti ntos nombres, estas referencias se denominan links . Tamao del archivo. Tabla de asignacin de DataBl ocks, un archivo puede estar almacenado en bloques contiguos o no; esta tabla contiene la direccin de los bloques que forman los archivos, cada uno de estos bloques se denomina DataBl ocks. Dado que los i-nodos son de tamao fi jo y que la cantidad de bloques del archivo corres pondiente al i-nodo puede ser muy grande, se necesita un mecanismo para referenciar las direcciones de bloques que no se puedan almacenar en el i-nodo, este mecanismo es el llamado mecanismo de indireccin , esto es, las primeras entradas corresponden a direcciones de bloques mie ntras que las siguientes referencian a bloques que contienen direcciones de bloques. Los niveles de indireccin pueden ser varios. La imagen 4.17 represe nta un esquema de indireccin de tres niveles. [2]
20
Tablas del Kernel: Los i-nodos se almacenan en los mismos dispositivos de almacenamie nto en los que reside el contenido de los archivos, sin embargo el sistema de archivos mantiene algunas tablas en memoria para agilizar y coordinar accesos a los archivos, estas son las siguientes: Tabla de i-nodos: Es una tabla global del kernel que por cada entrada contiene los datos de la i-nodo correspondiente, adems de la siguiente informacin: 1. Referencia al sistema de archivos en el que se encue ntra el archivo. 2. Contador de procesos que estn utilizando el archivo asociado al i-nodo en cuestin. 3. Nmero 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 encue ntra en espera para acceder al archivo asociado al i-nodo), indica adems si el i-nodo se modi c en memoria pero no se persisti en el medio de almacenamie nto, etctera. Tabla de archivos: Es una tabla global del kernel a la que se le agrega una entrada cada vez que se abre o crea un archivo. Esta entrada contiene un puntero al i-nodo corres pondiente de la tabla de i-nodos, adems y mantiene informacin adicional como la posicin de lectura o escritura dentro del archivo (o set), los permisos con los que el proceso accede al archivo, la cuenta del nmero 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 que un 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 de archivos e informacin adicional como le descriptor con el que el proceso acceder al archivo. Si un proceso abre dos veces el mismo archivo recibir dos le descriptor diferentes, cada uno estar asociado a una entrada diferente en la tabla en cuestin y cada una de estas entradas tendr un puntero diferente a la tabla de archivos; esta es la manera media nte la cual el kernel mantiene dos o sets diferentes al mismo archivo para el mismo proceso. Existen calls que permite evitar este comportamie nto. [2] Directorios: Un directorio es un archivo cuyo contenido es una secuencia de registros de longitud variable que contienen la longitud del registro, un nmero de i-nodo, la longitud y la secuencia de caracteres que represe ntan el nombre del archivo (asociado al i-nodo) con el que se ve dentro del directorio en cuestin. La escritura en los directorios se reserva al kernel, es decir, todas las escrituras sobre estos archivos se realizan media nte las system calls corres pondientes, esto permite gara ntizar la integridad del sistema de archivos. Los campos de permisos de los directorios tienen un signif i 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, etctera. La imagen 4.18 esquematiza un directorio. [2]
21
Buf f ering: Como se mencion anteriorme nte, los drivers de los dispositivos orientados a bloques se comunican con el sistema de archivos media nte una tcnica de buf f ering. La cantidad de buffer que el kernel administra es un parmetro del sistema operativo, y el control de los mismos se impleme nta media nte colas de dispersin dobleme nte enlazadas a las que se accede a travs de registros de cabecera. Los nodos de la cola de bloques, adems de estar enlazadas para conformar una cola de dispersin, tienen enlaces para conformar una cola de enlaces libres. Cada nodo de la cola de dispersin est formado por los siguientes datos: 1. Nmero de dispositivo. 2. Nmero de bloque. 3. Puntero a rea de datos. 4. Puntero al prximo registro de la cola de dispersin. 5. Puntero al anterior registro de la cola de dispersin. 6. Puntero al prximo buffer libre. 7. Puntero al anterior buffer libre. 8. Estado, este valor puede ser, bloqueado, datos vlidos, se debe escribir antes de reasignarlo, se est leyendo o escribiendo actualme nte, un proceso est esperando que se libere el buffer. Para buscar un bloque en la cola de dispersin se aplica una funcin de hash a la que se le pasa como parmetros el nmero de dispositivo y el nmero de bloque, en el caso de que el bloque buscado no se encuentre en la cola se lee 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 tena varios problemas en el rendimie nto. La imagen 4.19 nuestra una particin con ext-2 .
22
El bloque 0 contiene informacin para el inicio de la computadora, luego de este la particin se divide en conju ntos de bloques. El sper bl oque contiene informacin sobre la distribucin del sistema de archivos, incluyendo el nmero de i-nodos, el nmero de bloques de disco y el inicio de la lista de bloques libres. El descriptor de gru po contiene informacin de la ubicacin de los mapas de bits, el nmero de bloques libres, nmero de directorios y nmero de i-nodos en el conjunto de bloques. Los dos mapas de bits represe ntan los bloques libres y los utilizados. lo tanto la cantidad de bloques que pueden mapear est limitada. Estos mapas son de tamao jo, por
Por ltimo estn los i-n odos y luego los bl oques de dato s, aqu se almacenan todos los datos de los archivos y directorios, puede ocurrir que si un archivo es lo suf i cienteme nte extenso, los bloques que lo forman no sean contiguos, 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 fragmentacin 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 bsquedas de archivos en los directorios son secuenciales. En un directorio con muchos archivos esta operacin puede ser extremadame nte lenta, por lo tanto para evitar este problema se utiliza una cache de los directorios de acceso reciente. Para buscar en esta cache se utiliza el nombre del archivo, y de encontrarse el archivo se evita la lectura secuencial. [1]
23
4.7.5.
EXT-3
Este sistema de archivos es el sucesor de ext-2, y se caracteriza por tener una impleme ntacin de transacciones. Cada modif i cacin en el sistema de archivos se graba en un archivo secuencial, de esta manera si se produce una falla en el sistema, al iniciar nuevame nte se leer el archivo de transacciones y se efectuarn los cambios que no pudieron ser efectuados. Las operaciones de lectura y escritura sobre el archivo de transacciones no son realizadas por el sistema de archivos, sino que las realiza un dis positi vo de bl oque transaccional (JBD) .El JBD proporciona tres estruc turas de datos principales, el registro diario, el manejador de operaciones atmicas y la transacci n. Un registro diario describe una operacin de bajo nivel del sistema de archivos, que por lo general son cambios dentro de bloques. El sistema de archivos notifica al JBD sobre el inicio y el n de una llamada al sistema para que este pueda asegurar que se apliquen todos los registros diarios en una operacin atmica, o que no se aplique ninguno. El JDB elimina los registros diarios una vez que se verifica que se aplicaron los cambios que ellos represe ntan, de esta 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 a continuacin. 1. Es capaz de trab ajar con volmenes de hasta 1EByte y el tamao mximo de archivos es 16TByte. 2. El concepto de bloques utilizado en Unix se remplaza por exte nts, estos son grupos de bloques contiguos que permiten mejorar el uso de archivos de gran tamao y se reduce la fragme ntacin. 3. Se impleme nt una nueva llamada al sistema (preall ocate()) que se agreg al kernel de Linux, esta operacin realiza la reservacin de espacio para un archivo siendo muy probable que sea contiguo. 4. Se impleme nt una tcnica que mejora el rendimie nto llamada All ocate-on- us h, esta consiste en retrasar la reserva de bloques en memoria hasta que la informacin est a punto de ser persistida en la unidad de almacenamie nto. Esta tcnica mejora el rendimie nto y reduce la fragme ntacin al mejorar las decisiones de reserva de memoria basada en el tamao del archivo. 5. Se super el lmite 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 estn formados por dos partes, una seccin llamada Data fork y otra llamada resource fork. La seccin data fork contiene los datos creados por el usuario, en cambio la seccin resource fork contiene una cabecera de los recursos, los recursos propios y un mapa de los recursos. Entindase por recursos a conos, menues, controles de la aplicacin. [2] [3] [4] Un problema que tena el sistema de archivos predecesor a este, es que al momento de buscar todos los archivos dentro de un directorio deba acceder a un archivo en el que se almacenaba esta informacin, esta operacin para directorios con muchos archivos era lenta, por lo tanto la solucin impleme ntada fue crear el llamado catalog le (es un rbol B*) para realizar las bsquedas con mayor rapidez. Para realizar las bsquedas utiliza un mdulo llamado finder 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.
24
Las principales estructuras de este sistema de archivos se analizan a continuacin: 1. El sector de arranque del volumen contiene informacin para el inicio del sistema, por ejemplo el nombre del archivo de shell y del f i nder que se cargan al iniciar. 2. El directorio MDB (Master directory block), tiene la informacin de la particin y dnde localizar las dems estructuras. 3. Mapa de bits de bloques para determinar los que estn libres y los que no. 4. El catalog le que es un rbol B* que contiene informacin para todos los archivos y directorios almacenados en el volumen. Cada archivo consiste en un le thead record y un le recor d, mientras que cada directorio consiste en un directory thead record y un directory recor d. Un le thread record almacena slo el nombre del archivo y el CNID (catalog node id) de su directorio padre. Un le record almacena varios metadatos como son el CNID y tamao del archivo, tres timestamps (creacin, modif i cacin y cundo se realiz la ltima copia de seguridad), datos referidos a los recursos, y un puntero al primer bloque de datos del archivo. Tambin, almacena dos campos de 16 bytes que son usados por el f i nder para acelerar las bsquedas de archivos. Un directory thread record almacena slo el nombre del directorio y el CNID del directorio padre. Un directory record almacena datos como el nmero de cheros almacenados en el directorio, el CNID del directorio, tres timestamps (creacin, modif i cacin y ltimo backup), almacena dos campos de 16 bytes para uso del f i nder. 5. El archivo de desbordamie nto que se utiliza en el caso de que algn archivo tenga su sector data fork desbordado, 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 direccionamie nto es de 16 bits si el volumen es grande los bloques tendrn demasiado tamao y se desperdiciar demasiado espacio cuando un archivo no ocupe al 100 % todos sus bloques. 2. Cada vez que se modifica un archivo o directorio se accede al catalog le, dado que ms de un proceso no puede modificar esta estructura al mismo tiempo los procesos quedan en cola esperando su turno, esto reduce 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 informacin de los archivos y directorios est en ste y no distribuida. 4. Para direccionar bloques se utiliza un nmero de 16 bits, por lo tanto la cantidad de bloque para un archivo se limita a 65536. [2] [3]
25
4.7.8.
HFS+ (HFS plus)
Este sistema de archivos se cre para reemplazar a HFS, tiene varias mejoras comparadas con el anterior que se enumeran a continuacin: 1. El mapa de bits fue reemplazado por un archivo, de esta manera se puede increme ntar si la particin crece, este nuevo archivo es llamado all ocation le. 2. El direccionamie nto a los bloques se realiza media nte un nmero de 32 bits, con esto se termina la limitacin de 65536 bloques mximos para un archivo. 3. Los registros del catalog le (B *) son de mayor tamao.
4. Los bloques daamos se ubican en el archivo de desborde. 5. Se impleme nt un nuevo archivo (B*) llamado atribu tes le para direccionar atributos, este archivo es utilizado por el f i nder para mejoras la velocidad de respuesta de las bsquedas. 6. El MDB fue reemplazado por un header que contiene informacin sobre el volumen. 7. Se impleme nt un nuevo archivo de inicio, llamado startup le, que es utilizado para sistemas de archivos que no son HFS o HFS+ puedan utilizar la interfase de acceso a los archivos. 8. El nombre de los archivos soporta caracteres 4.7.9. HPFS Unic ode. [2] [5]
Este sistema de archivos fue creado especf i came nte para el sistema operativo OS/2 mejorando algunas de las limitaciones de FAT. Algunas de las caractersticas se mencionan a continuacin: 1. La ordenacin de los directorios se basa en el nombre de los archivos. 2. Utiliza una estructura ms ef i cie nte para organizar los directorios, de esta manera, se utiliza menos espacio en el almacenamie nto y el acceso a los archivos es ms rpido con respecto a FAT. 3. Los archivos se ubican en sectores en vez de clusters. 4. Para la administracin 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 informacin contenida en l se mueve a otro. [2] 4.7.10. ZFS
Este sistema de archivos se destaca por tener una gran capacidad, integracin de conceptos (anteriorme nte separados) como sistema de archivos y administrador de volmenes, sencilla administracin del espacio de almace namie nto. Algunas de las caractersticas se mencionan a continuacin: 1. Los punteros a bloques contienen un checksum de 255 bits sobre el bloque apu ntado que se comprueba cada vez que se lee el bloque en cuestin. Los bloques que contienen informacin activa no se sobrescriben nunca, en su lugar se reserva un nuevo bloque y los datos modif i cados se escriben en l, por lo tanto cualquier bloque de metadatos que lo referencie es reubicado y escrito de manera similar. Para reducir la sobrecarga que genera este proceso, se agregan varias actualizaciones en grupo de transacciones, y se utiliza un log de intentos cuando se necesitan escrituras sincrnicas. 2. Utiliza bloque de tamao variable hasta 128KB, adems soporta compresin de bloques, en el caso de activarse la compresin se disminuye el uso de espacio, pero se increme nta el trab ajo de procesador. 26
3. A medida que se agregan dispositivos, el ancho de banda se expande de forma automtica para incluirlos, de manera 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 espacios de almacenamie nto virtuales. Estos se constru yen a partir de uno esta manera el sistema de archivos puede estar montado en un dispositivo almacenamie nto del que se necesita y utilizar otros para compensar la falta un solo dispositivo, ZFS utiliza o ms dispositivos virtuales, de que tenga menor capacidad de de espacio. [8]
27
5 RELE VAMIENTO BIBLIOGRFICO DE MTODOS Y TENDENCIAS PARA OPTIMIZAR EL RENDIMIENTO DE SISTEMAS DE ARCHIVO
5.
Rele vamie nto bibliogr fi co de mt odos y tendencias optimizar el rendimie nto de sistemas de ar chi vo
para
En esta etapa se analizarn las lneas de investigacin sobre las siguientes problemticas en los sistemas de archivo, prdida de performance en el tiem po de accedo debido al no cumplimie nto del principio de localidad, y aplicacin de bu ff er-ca che para la optimizacin de tiem pos de acces o.
5.1.
Fragme ntacin en sistemas de archivos y Principio

Fragme ntacin de
de localidad
5.1.1. ar chi vos
Al crear, copiar o mover un archivo en la unidad de almacenamie nto, el sistema operativo busca bloques de espacio libre en disco contiguo, donde puede escribir el archivo. Cuando el sistema ope rativo no puede enco ntrar su ciente espacio contiguo, busca el espacio libre no contiguo necesario en la unidad de almacenamie nto. Como resultado, los bloques del archivo pueden quedar dispersos en lugar de un rea contigua de la unidad de almacenamie nto. Cuando los bloques de un archivo quedan dispersos se conoce como un archivo fragme ntado. Acceder a un archivo implica que se localicen los n bl oques que lo forman para obtener toda su informacin, para realizar el acceso a un bloque primero debe ser ubicado debajo de la unidad de lectura (tiem po de seek ), si el archivo est fragm ntado este tiempo ser mayor que el tiempo de acceso de un ar chi vo no fragme ntad o. e [16] En la imagen 5.1 se visualiza la distribucin de los bloques que forman un archivo.
5.1.2.
Principio
de localidad
El principio de localidad plantea el siguiente escenario, dado un ar chi vo A formado por n bl oques, es conveniente tenerlos ubicados de manera que el tiem po de seek sea el mnimo posible. La fragme ntacin en los archivos genera que los bloques de los mismos no cumplan con el principio de localidad. 28
Para represe ntar esta problemtica se plantea el siguiente escenario, en el tiem po t1 se crea el ar chi vo A formado por 10 bl oques ubicados de manera co ntigua. En el tiem po t2 se borran 5 bloques del ar chi vo A. En la imagen 5.2 se plantea cmo queda formado en archivo A en el tiempo t2 .
En el tiem po t3 se crea el archi vo B formado por 4 bl oque s, estos se insertan en los bloques libres antes fueron ocupados por los bloques del archivo A. En la imagen 5.3 se muestra la distribucin de los bloques en el tiempo t3 .
En la situacin planteada se deduce de qu manera se pierde el principio de localidad con el transcurso del tiem po, a causa de este motivo se ve increme ntado el tiempo de lectura del archivo A. El escenario planteado es extremadame nte bsico, pero en un sistema de archivos real el efecto causado por la manipulacin de sus archivos es que el principio de localidad deje de cumplirse para muchos de estos y la performance se vea decreme ntada, estudios como los que se plantean en [13] indican este fenmeno.
5.2.
Desfragme ntacin y tcnicas archi vos actuales
para reducir
la fragme ntacin en sistemas
de
La desfragme ntacin en sistemas de archivos es el proceso en el cual se realizan tareas de reubicacin de los bloques de los archivos de manera tal que queden en una zona contigua de la unidad de almacenamie nto, el n
29
de esto es que se cumpla con el principio de localida d. A continuacin se analizan los procesos de desfragme ntacin en varios de los sistemas de archivos actuales. 5.2.1. Familia FAT Sistemas de de ar chi vos W ind ows de ar chi vos
sistemas
El proceso de desfragme ntacin en los sistemas de los archivos fragme ntados. Los pasos son los siguientes:[10]
de ar chi vos FAT se basa en la reubicacin de los bloques
1. Anlisis del espacio libre en la unidad de almacenamie nto. En el proceso de desfragme ntacin se realizan copias temporales (una por archivo fragme ntado), por este motivo es necesario disponer de espacio en la unidad de almacenamie nto para realizar las copias necesarias. Estos nuevos archivos tienen los bloques ubicados de manera que cumplan el principio de localidad lo ms que sea posible. 2. Deteccin de los archivos fragme ntados. Esta etapa del proceso se encarga de buscar todos los ar chi vos fragme ntados, para este n se calcula su nivel de fragme ntacin (cantidad de bloques no contiguos) y se compara con un valor determinado para decidir si se desfragme nta o no. En este anlisis se evitan los archivos que son utilizados por el sistema operativo para su conf i guracin y correcto funcionamie nto, archivos defectuosos. 3. Copia de los bloques de los archivos enco ntrados en el paso 2. A travs de la FAT se obtienen las direcciones de los bloques que forman los archivo detectados en el paso 2, luego se copian de manera contigua en un sector de la unidad de almacenamie nto con el espacio necesario para ello. 4. Comparacin de los archivos originales con los nuevos. Esta etapa se encarga de corro borar que los archivos originales y las copias generadas sean idnticas para evitar prdidas de informacin o inconsistencias. 5. Reemplazo en la FAT de los nmeros de bloques. Las referencias a los bloques que forman los archivos referencias de las copias generadas . desfragme ntados son modif i cadas por las
6. Borrado de los bloques originales. En esta etapa se eliminan los archivos originales, esto se debe a que ya no son utilizados porque fueron reemplazados por los que se generaron en el paso 3. Familia NTFS de sistemas de ar chi vos que los de la familia FAT, las tabla FAT, sino que utiliza una que forman los archivos, por lo se modif i can las referencias de
En el caso de los sistemas de ar chi vo NTFS, los pasos son los mismos diferencias se dan en los pasos 2 y 5. Esto se debe a que NTFS no utiliza una tabla llamada M FT. En esta tabla se almacenan las referencias a los clusters tanto es de aqu de donde se toman las referencias para el paso 2, y es donde los clusters de los archivos originales.
Los sistemas operativos windows se basan en que el usuario decida ejecutar el proceso de desfragme ntacin. Desde la versin de Windows Vista existe un proceso que se ejecuta background y realiza tareas de desfragme ntacin.[10] 5.2.2. Sistemas de ar chi vos Unix
Los sistemas de archivos Unix, para reducir la fragme ntacin, impleme ntan una tcnica llamada agrupacin por cilindros . Esta tcnica se basa en dividir el espacio fsico de la unidad de almacenamie nto en cilindros. La condicin que se aplica sobre los archivos es que sus bloques estn en el mismo cilindro, y en caso de que no quepan en uno, se ubican en cilindros cercanos. Con esta tcnica se logra mejorar el principio de localidad y disminuir la fragme ntacin ya que la separacin de 30
los bloques est limitada a los cilindros o a cilindros cercanos.[12] Est tcnica es utilizada en sistemas de archivos como EXT-2, EXT-3 y EXT-4 . Existen herramie ntas como e2defrag (se utiliza en EXT-2) que realizan la desfragme ntacin y que deben ser ejecutadas por el usuario. La desfragme ntacin en sistemas de Unix se basa en la reubicacin de los bloques que forman los archivos hacia un mismo cilindro o a cilindros cercanos; adems de deben actualizar las i-nodos de los archivos para que direccionen las nuevas ubicaciones de los bloques. 5.2.3. Sistema de archi vos EXT-3
Para este sistema de archivos existen herramie ntas para la desfragme ntacin como Sha ke y Defrag. Shake trab aja reservando espacio para todo el archivo de manera que sus bloques queden ubicados en sectores contiguos, para esto se busca el espacio necesario en toda la unidad de almacenamie nto. Defrag copia los bloques de los archivos de manera contigua comenzando en la ubicacin fsica del primer bloque del archivo. Para esto necesita que la unidad de almacenamie nto tenga mucho espacio libre para hacer copias temporales del contenido de los bloques que se reemplazan. Una tcnica utilizada por este sistema de archivos para reducir la fragme ntacin es la llamada copy-on-write , este mtodo se basa en asignar los mismo bloques para los disti ntos archivos al momento de reservar espacio libre, pero al mome nto de persistir la informacin se asignan bloques nuevos para el archivo en cuestin.[11] 5.2.4. Sistema de ar chi vos EXT-4, HFS+, ZFS
Estos sistemas de archivos utilizan el mtodo llamado del ay ed all ocation , este consiste en retrasar la reserva de bloques hasta que la informacin est a punto de ser escrita en el disco, a diferencia de otros sistemas de archivos, los cuales reservan los bloques necesarios antes de ese paso. Esto mejora el rendimie nto y reduce la fragme ntacin al mejorar las decisiones de reserva de bloques basada en el tamao real del archivo.[14] 5.2.5. des ventajas Venta jas y
Varios de los sistemas operativos no ejecutan el proceso de desfragme ntacin de manera automtica, requieren que el usuario lo indique. Esto es una gran des venta ja ya que muchos usuarios no conocen la existencia de estas herramie ntas. Algunos sistemas de archivo impleme ntan diferentes tcnicas para disminuir la fragme ntacin, otros no, lo cual es una des ventaja.
5.3.
Lneas de investigacin de archivos modernos
sobre tcnicas para evitar la fragme ntacin en sistemas
En esta seccin se tratarn en detalle tcnicas utilizadas para evitar la fragme ntacin en sistemas de archivos Unix y NTFS. 5.3.1. Sistemas de ar chi vos Unix
Como se mencion en secciones anteriores, cuando se graban los bloques de un archivo, estos pueden ubicarse en secciones no contiguas de la unidad de almacenamie nto; esto provoca que al momento de leer dichos bloques, la unidad de lectura necesite realizar movimientos por varias pistas de la unidad de almacenamie nto. El efecto de realizar dichos movimientos es que perjudica la performance del sistema de archivos. La solucin plateada por Unix para resolver este problema es la llamada agrupacin por cilindros (ima gen 5.4); esta tcnica se basa en dividir la unidad de almacenamie nto en cilindros, es decir, agrupar un nmero de pistas de la unidad de almacenamie nto en un cilindro.[12] Al momento de realizar la persistencia de los bloques del archivo se ubican segn la poltica que se describe en la siguiente seccin. De esta manera se reduce el tiempo de acceso a los bloque de los archivos ya que el movimiento de la unidad de lectura sobre la unidad de almacenamie nto se reduce de manera considerable ya que el tiempo de acceso est totalme nte relacionado con el tiempo de posicionamie nto de la unidad de lectura, por lo tanto, al disminuir dicho tiempo reducimos el tiem po de acces o.
31
Cuando se necesita asignar espacio a un archivo o directorio, se ejecuta la siguiente heurstica que consta de cuatro etapas: 1. Se busca el bloque ms cercano al actual dentro del mismo cilindr o. 2. Si no se encue ntra ningn bloque disponible en el mismo cilindr o, se asigna un bloque de otro cilindro del mismo gru po de cilindro s. 3. Si el grupo de cilindros est totalme nte llen o, se utiliza una funcin de hash para obtener el nmero de otro grupo de cilindros en el que se repiten los pasos uno y dos . 4. Finalme nte, si el paso tres falla, se busca en todos los gru pos de cilindro s. La heurstica prese ntada es la utilizada para directorios. la asignacin de bloques a los archivos y
Cada grupo de cilindros contiene informacin acerca de los bloques que almacena: 1. Un Bitmap que indica los bl oques libres .
2. La lista de i-n odos que contiene. 3. Una copia del super bl oqu e. En el trab ajo [12] se realizaron pruebas relacionadas con el rendimie nto de esta tcnica, demostraron que genera mejoras en la performance ya que los tiempos de acceso bajaron con respecto a un sistema de archivos que trab aja sin respetar el principio de localidad.
32
5.3.2.
Sistemas
de ar chi vos NTFS
Basado en el principio de localidad los clusters de un archivo se almacenan de manera contigua siempre que sea posible. Cada conjunto de clusters contiguos de un archivo se describe media nte un registro; si un archivo est formado por ms 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 que represe nte ambos conjuntos. Cada registro comienza con un encabezado que proporciona el desplazamie nto de los datos del primer conjunto dentro del registro, luego el desplazamie nto del siguiente conjunto, y as sucesivamente. Cada encabezado va seguido de uno o ms pares, cada uno de los cuales proporciona la direccin del primer cluster del conjunto (de clusters contiguos) y la longitud del conjunto; la direccin es respecto al comienzo de la particin. La imagen 5.5 represe nta un registro de la MFT para tres conjuntos de clusters consecuti vos. En el caso en que el archivo sea tan grande o tan fragme ntado y la informacin de los clusters no entre en un registro de la MFT se utilizan varios registros para este n. Tendremos un registro base y varios registros de extensin segn se necesite.
En el caso en que se necesiten tantos registros de la MFT tal que no haya espacio su cie nte en la MFT base para listar todos sus ndices se utilizan clusters extras (no pertenecen a la MFT base) para colocar esta informacin, de esta manera puede crecer todo lo que sea necesario. En la 5.6 se muestra una entrada en la MFT para un directorio pequeo. El registro contiene varias entradas de directorios, cada una de las cuales describe a un archivo o directorio. Cada entrada tiene una estructura de longitud ja seguida de un nombre de archivo de longitud variable. La parte ja contiene el ndice de la entrada en la MFT para el archivo, la longitud del nombre del archivo y una variedad de campos y ags adicionales. Para
33
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 forma lineal, se utiliza un rbol B+ para que sean bsquedas ptimas.
Para realizar la bsqueda del archivo C:\f oo\bar se realizan las siguientes acciones, se efecta un anlisis de la ruta \foo\bar que comienza en el directorio raz C: cuyos bloques se pueden enco ntrar desde la entrada 5 de la MFT (por ejemplo), la cadena foo se busca en el directorio raz 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. Luego de 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 tcnica se logra tener la informacin que forma a los archivos de manera tal que se cumple el principio de localidad en una buena medida, y por lo tanto la performance crece. 5.3.3. EXT-4
Este sistema de archivos introduce tres nuevas tcnicas para reducir la fragme ntacin de los archivos, estas son exte nts, preall ocate y all ocate-on- ush .[15] Exte nts: Ext3 utiliza un alocador de bloques que decide cules de los que se encue ntran libres van a ser utilizados para escribir los datos, para llevar a cabo esta accin se realiza una llamada por bloque, lo cual es ine cie nte por ser demasiadas llamadas las que se realizan. Para mejorar este aspecto Ext4 incorpora un alocador multi-bloques que en una sola llamada aloca todos los bloques (en lo posible de manera contigua) necesarios, este conjunto de bloques es denomina extends .
34
Las estructuras utilizadas phara el funcionamie nto de esta tcnica son las siguientes: /* * This is the exte nt on-disk structure. * It's used at the bottom of the tree. */ struct ext4_exte nt { le32 ee_bl ock; /* rst logical block exte nt covers */ le16 ee_len; /* number of blocks covered by exte nt */ le16 ee_start_hi; */ le32 ee_start_lo; */ };h /* * This is index on-disk structure. * It's used at all the levels except the bottom. */ struct ext4_exte nt_idx { le32 ei_bl ock; /* 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; u16 ei_u nused; }; Estas dos estructuras represe ntan las hojas (ext4_exte que se utiliza para acceder al extend. nt) y los nodos internos (ext4_exte nt_idx) del rbol /* high 16 bits of physical block */ /* high 16 bits of physical block /* low 32 bits of physical block
Preall ocat e: Para increme ntar la probabilidad de que los bloques asignados a un Extend sean contiguos es necesarios reservarlos lo ms rpido posible, para esto se impleme nt una nueva SystemCall (preall ocate) al kernel de Linux, esta operacin realiza la reserva de bloques cuando es invocada. All ocate-on- ush: Una tcnica que tiene la misma nalidad que Preall ocate (trab ajan de manera diferente y tienen el mismo propsito) es All ocate-on- ush, esta consiste en retrasar la reserva de bloques hasta que la informacin est a punto de ser persistida en la unidad de almacenamie nto. Esta tcnica mejora el rendimie nto y reduce la fragme ntacin al mejorar las decisiones de reserva de memoria basada en el tamao del archivo.
5.4.
Bu er-ca che para la optimizacin
de tiem pos de acceso
Como se mencion anteriorme nte, 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 encue ntra el sector a leer o escribir (tiem po de seek). 2. El tiempo de rotacin para que el sector a leer o escribir se encuentre con el cabeza l(tiem po de latencia). 3. El tiempo de lectura o escritura (tiem po de transferenci a).
Estos tiempos no son menores, por lo tanto se pueden aplicar tcnicas para reducirlos, una de estas es la utilizacin de bu er-ca che .
35
5.4.1.
Bu er-ca che
El bu er-ca che es una cache de bloques y su objetivo es minimizar accesos a la unidad de almecenamie nto, el por qu de este objetivo es que el acceso a la unidad de almacenamie nto para acceder a bloques es de varios rdenes mayor que el tiempo de acceso a la memoria principal. Una manera de impleme ntar esta tcnica es media nte listas enlazadas en memoria donde cada dispositivo de almacenamie nto tiene asociada una o ms listas de bloques, las mismas se acceden media nte una hash que se calcula con la direccin del dispositivo. La imagen 5.7 muestra una ejempli cacin de la impleme ntacin del bu er-ca che media nte listas enlazadas.
5.4.2.
Poltica de reemplazo
de bloques
En ocasiones se quiere insertar un nuevo elemento en alguna de las listas estando llena, cuando esto ocurre se debe impleme ntar algn tipo de poltica de reemplazo.
36
Una posibilidad (y la ms utilizada) es la tcnica denominada LRU, esta consiste en reemplazar el elemento que tiene mayor tiempo sin accederse. La imagen 5.8 represe nta el proceso de reemplazo de un bloque segn la poltica LRU.
Cada uno de los bloques cargados en las listas tienen un status que re eja su estado. A modo de optimizacin, cada bloque se mantiene en memoria sin persistir su informacin en la unidad de almacemamie nto hasta que se reemplace por otro, por lo tanto en el momento en que se reemplace se analizar su status para saber si debe ser persistido en la unidad de almacenamie nto o no. A continuacin se prese nta una heurstica que represe nta 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 almacenamie nto.
37
5) Se inserta el nuevo bloque en la lista.
5.4.3.
Sincronizacin
para el reemplazo
de bloques
Esta tcnica tiene problemas de sincronizacin al momento de querer modi car o reemplazar uno de los bloques que est en alguna de las listas. Un mtodo para evitar este problema es analizar el status del bloque, si el status indica que el bloque est siendo utilizado por otro proceso, el proceso que quiere tomar el bloque queda en espera hasta que quede libre. Este es el mecanismo ms tradicional y ms simple para sincronizar el acceso a los nodos de la lista. La imagen 5.9 represe nta el proceso de sincronizacin de bloques.
A continuacin se prese nta una heurstica para este proceso: 1) Se accede a un bloque de la lista.
38
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. Optimizacin en la performance del bu er-ca che por medio de algoritmos informacin de la carga del sistema que utilizan
En el trab ajo [17] se analiz una optimizacin para el mtodo de bu er ca che que consiste en lo siguiente, se propone una serie de algoritmos que permiten realizar la escritura de los bloques de manera sincrnica. Estos algoritmos utilizan la cantidad de procesos corriendo en el sistema y la longitud de la cola de la cache, esta informacin se obtiene de manera dinmica dura nte la ejecucin de los algoritmos. El rendimie nto de las operaciones en el bu er-ca che se mejora media nte el uso de estos algoritmos que permiten escribir el contenido del bu er-ca ch en la unidad de almacenamie nto en funcin de la carga del sistema y la actividad de escritura. La conclusin del trab ajo es que el tiempo de la escritura de un archivo se reduce con la utilizacin de los algoritmos que escriben los bloques en la unidad de almacenamie nto en funcin de la tasa de operaciones de escritura y el nmero de procesos activos en el sistema. Se demostr que los algoritmos propuestos perm iten un mejor rendimie nto que un algoritmo que no utiliza informacin sobre la carga del sistem a. 5.4.5. Optimizacin actualizacin en la performance del bu er-ca che por medio de mejoras en la poltica de
Cuando los bloques son modi cados deben ser escritos en la unidad de almacenamie nto, esto se realiza inmediatame nte, de m anera retardada o peri dicame nte, en el trab ajo [18] se analiz una posible optimizacin para el mtodo de bu er cache que consiste en realizar una aplicacin aproximada a una poltica de intervalo de actualizacin peridica, en la que se escribe el bloque en la unidad de almacenamie nto cuando cumple cierto tiempo de estar en estado modi cado. En la experime ntacin se ejecutaron dos procesos corriendo al mismo tiempo: Un generador Un generador de escritura s, con gurado para realizar escrituras cada 30 segundos. de lectura s, en el mismo 10.000 bloques son elegidos al azar.
Adems se utilizaron dos sistemas de hard ware diferentes, uno ms rpido que el otro. En el trab ajo en cuestin se ejecutaron varios benchmarks que arrojaron los siguientes resultados, el uso de escritura retardada puede mejorar los tiempos de accesos, pero cuando la escritura retardada se combina con la tcnica planteada, los tiem pos de respuesta m ejoran de m anera signi cati va. 5.4.6. Colas mltiples de reem plazo para el segundo nivel de bu er-ca che
En el trab ajo [19] se plante un nuevo nivel de bu er cache con un algoritmo que utiliza colas mltiples para alocar los bloques. Originalme nte el plateo est destinado a servidores distribuidos, pero esta idea puede aplicarse a una computadora local que trab aja con los dos niveles de bu er cache. La imagen 5.10 represe nta la estructura necesaria media nte un diagrama de bloques.
39
El algoritmo utilizado mantiene los bloques en el segundo nivel de bu er cache, cada bloque tiene asociada una frecuencia de acceso. Las colas tienen asociadas un rango de frecuencias de accesos admisible, slo si un bloque tiene 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 a continuacin: En un hit, el bloque es removido de la cola en donde est alocado y es reubicado en la cola que le corres ponda segn su frecuencia de acceso. En un miss, el bloque es ubicado en la cola corres pondie nte a la menor frecuencia de accesos posible. A continuacin se prese nta el pseudocdigo del algoritmo MQ:
40
La conclusin del trab ajo es que el ratio de hits se increme nta en un 10 % respecto a la no utilizacin de la tcnica plateada, por lo tanto los tiempo de acceso a bloques decrecen.
41
6 ELABOR ACIN DE UNA PROPUES TA DE SOLUCIN ALTERN ATIVA O
6.
Ela boracin de una propuesta
de solucin alternati va o superadora
La propuesta a la problemtica planteada consiste en una tcnica que se forma a partir de dos subtcnicas, Localidad de archivos asociados y Ejecucin de pr ocesos en ba ckground para increme ntar la performance , estas dos tcnicas se van a compleme ntar para formar la propuesta nal. Adems se deben realizar modi caciones en las estructuras de los sistemas de archivos para darle soporte a esta nueva tcnica, en el actual trab ajo se plantearn las nuevas estructuras y modi caciones en general, quedando para trabajos a futuros realizar las impleme ntaciones 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 fenmeno permite plantear que estos archivos estn relacionados. La tcnica de Localidad de archivos asociados se basa en los siguientes principios: 1. Favorece a la performance que los archivos relacionados estn ubicados lo ms cercaname nte posible dentro de la unidad de almacenamie nto (principio de localidad), el caso ideal es que estn ubicados adyacenteme nte. 2. Favorece a la performance que los bloques que forman un archivo estn ubicados lo ms cercaname nte posible dentro de la unidad de almacenamie nto (ar chi vos no fragme ntados), el caso ideal es que estn ubicados adyacenteme nte. 6.1.1. Algoritmo de principio de localidad en ar chi vos asociados
Para cumplir con el principio de localidad, esta tcnica plantea lo siguiente: Todos los archivos accedidos por un mismo proceso estn relacionados, por lo tanto debe armarse el producto cartesiano de relaciones entre los mismos. El mismo mtodo debe repetirse para todos los procesos. Todas las relaciones registradas deben fusionarse armando las ternas (ar chi vo 1, ar chi vo 2, ca ntidad de repeticiones de la relacin) y luego deben ser ordenadas segn cantidad de ocurrencias y en caso de empate por id de archivo. Los archivos se identi can media nte un id, en Unix puede ser el nmero de I-nodo por ejemplo. La informacin de relaciones generada debe ser fusionada con los resultados histricos de este anlisis para todos los procesos. En caso de que un proceso acceda a un nico archivo, no se registra ninguna relacin. A continuacin se prese nta una ejempli cacin de este proceso. Universo de archivos: A, B, C, D, E, F, G, H, I
42
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 histrico para tener el resultado global de relaciones. La imagen 6.2 represe nta el resultado nal luego de reubicar los archivos segn la tabla de relaciones. Este proceso debe realizar la modi cacin de todas las referencias fsicas (por las nuevas ubicaciones) de los bloques de los archivos para ma ntener la integridad del sistemas de archivos.
43
6.1.2.
Heurstica
para el algoritmo
de principio
de localidad en ar chi vos 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 (ar chi vo 1, ar chi vo 2, ca ntidad 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 histricas (evitando repetidas). 7) Volver al paso 2. 8) Ubicar de manera contigua los archivos segn la tabla histrica de ternas, en caso de que no existan los bloques contiguos libres necesarios, ubicarlos de la manera ms cercana posible. 6.1.3. M odo para evitar la fragme ntacin en ar chi vos asociados t
Los bloques de un archivo (con el pasar del tiempo) dejan de estar ubicados de manera contigua en la unidad de almacenamie nto. Como ya se mencion, este fenmeno provoca la fragme ntacin y la consiguiente prdida de performance. Para evitar este problema los bloques de los archivos deben ser reubicados de manera contigua. 6.1.4. Resultado de la reubicacin de archi vos segn las relaciones
El resultado de la reubicacin de los archivos relacionados nos gara ntiza dismi nuir la fragme ntaci n, as como tener ubicados de manera adyace nte los que estn relacionados. La disminucin de la fragme ntacin ocurre porque al momento de reubicar los archivos (segn las relaciones de los mismos) se trata de ubicar los bloques de manera contigua. De esta manera se logra disminuir el tiempo de seek para la lectura de los bloques, as como tambin el tiempo de seek para el posicionamie nto sobre los archivos que utilizan los procesos por estar ubicados de manera adyacente. La tabla histrica de relaciones de ar chi vos no debe eliminarse nunca, lo que se debe hacer es depurarla ya que con el tiempo se eliminan algunos archivos, esto se analizar en la siguiente seccin llamada depuracin de la tabla histrica de relacione s.
6.2.
Persistencia
tem poral de los accesos a archi vos por los pr ocesos

de principio de localidad
Las relaciones entre archivos deben ser persistidas para poder realizar el algoritmo en archivos asociados (6.1.1 ), para esto se plantea la siguiente estructura:
Una cola compartid a, la cual tendr en cada nodo una lista de archivos accedidos por un proceso determinado(imagen 6.3), sta ser manipulada por el sistema de ar chi vos. Cada proceso tendr una lista propia, siempre que se ejecute una llamada al sistema (syscall) para acceder a un archivo no presente en dicha lista, sta ser actualizada con el nmero de id del archivo (accin que realizar el sistema de archivos).
44
Esta estructura ser analizada por un proceso (analizado en secciones posteriores) que se encargar de leer y modi car todas las estructuras necesarias para llevar a cabo el algoritmo 6.1.1. La imagen 6.4 represe nta la actualizacin de la cola compartida de archivos accedidos.
45
6.3.
Depuracin
de la tabla histrica
de relaciones
Con el paso del tiempo los archivos tienden a ser eliminados de la unidad de almacenamie nto, por lo tanto la tabla global de relaciones deja de tener coherencia con respecto a lo archivos almacenados. La tabla de relaciones crecer indefectibleme nte con el paso del tiempo, por lo tanto su lectura ser cada vez ms 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 de be represe ntar ar chi vos que existan en la unidad de almacenamie nto. La solucin para este problema es depurar la tabla tn formadas por al menos un archivo que no exista. La imagen 6.5 represe nta el proceso de depuracin. global de relaciones para eliminar aquellas que es-
Como se observa en la imagen, el tamao de la tabla de relaciones baja considerableme nte al ser depurada.
6.4.
Mdulos que forman la solucin
Para la solucin de niti va se plantea la utilizacin de una serie de mdulos que sern orquestados por otro, a continuacin se detalla cada uno de los ellos. 1. Mdulo que impleme nta el algoritmo 2. Mdulo de merg e. del principio de localidad en archi vos asociados (6.1.1 ).
46
3. Mdulo de reubicacin 4. Mdulo orquestado r. 5. Mdulo de depuracin 6. Mdulo de rollba ck. 6.4.1.
de bl oque s.
de la tabla histrica
de relacione s.
Mdulo que impleme nta el algoritmo
del principio
de localidad en ar chi vos asociados
Este mdulo 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 punto anterior. Guarda la salida del algoritmo en una estructura temporal que ser accedida posteriorme nte por el mdulo de merge. 6.4.2. Mdulo de merge
Este mdulo tiene como responsabilidad acceder a la estructura temporal generada por el mdulo del punto 6.4.1 y realizar un merge de los datos de dicha estructura con la tabla histrica de relaciones. El resultado de este proceso es la tabla histrica de relaciones actualizada y lista para ser procesada por el mdulo de reubicacin de bloques. 6.4.3. Mdulo de reubicacin de bl oques
Este mdulo debe accede a la tabla histrica de relaciones y por cada entrada de la misma realiza la operacin de reubicacin de bloques. Este proceso se ejecuta para la tabla completa y debe mantener actualizado el nmero de registro que est ejecutando, cuando procesa el ltimo registro naliza su ejecucin y el nmero de registro de la tabla histrica de relaciones se setea en uno. La reubicacin de bloques se efecta generando una copia (que cumple el principio de localidad) de los bloques de los archivos, una vez efectuada esta operacin se modi can todas las referencias a los archivos que pertenecen a los bloques reubicados de manera tal que al acceder a los mismos se acceda a los nuevos bloques. La ltima accin es marcar como libre los bloques que anteriores formaban los archivos para que puedan ser utilizados cuando sea necesario. 6.4.4. Mdulo orquestador
Este mdulo es el encargado de orquestar la ejecucin de todos los dems, la manera de orquestar es la que se prese nta en la imagen 6.6.
47
6.4.5.
Heurstica
para la ejecucin
del mdulo de orquestacin
1) Ejecucin del mdulo del principio de localidad y generacin de la estructura temporal con el resultado. 3) Ejecucin del mdulo de merge. 4) Ejecucin del mdulo de reubicacin de bloques. 5) Para cada entrada en la tabla histrica de relaciones ejecutar la operacin de reubicacin.
48
6.4.6.
Mecanismo
de log para m ntener la consistencia a
en caso de falla
En ocasiones puede ocurrir que dura nte la ejecucin del mdulo orquestador el sistema falle (corte de luz por ejemplo), esto puede generar que el sistema de archivos deje de ma ntener la consistencia. Para solucionar este problema se plantea lo siguiente, crear una estructura de log que sea analizada por el sistema de archivo cuando inicia y en caso de ser necesario ejecute las acciones necesarias para que vuelva a tener consistencia. La estructura planteada es la que se prese nta en la imagen 6.7.
Cada vez que el mdulo de reubicacin inicie su operacin sobre ambos archivos, se vaca la estructura y se setea el campo START para indicar el comienzo de dicha operacin, as como el segundo campo que indica el nmero de registro de la tabla histrica de relaciones que est siendo procesado, estos dos campos se setean de manera conju nta. Cuando nalice completame nte la ejecucin de reubicacin de bloques y modi cacin de referencias se setea el campo END que indica que se termin de ejecutar de manera satisfactoria el proceso de reubicacin. El proceso de log se realiza siempre que se ejecute la reubicacin de bloques para un registro de la tabla histrica de resultados. Cuando arranca el sistema de archivos se analiza esta estructura, en caso que exista el campo START y no el campo END implica que hubo un error dura nte la ejecucin del mdulo de reubicacin para el nmero de registro en cuestin, por lo tanto lo que se hace es deshacer los cambios realizado s, que en el peor de los casos es marcar como libre a todos los nuevos bloques que fueron copiados. Para llevar a cabo esta accin es necesario tener persistidos los datos corres pondientes a los nuevos bloques, estos se persistirn en una estructura que se plantea 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 ma ntener consistencia luego de una falla en el sistema.
En esta estructura se guarda la referencia a los nuevos bloques creados dura nte el proceso de reubicacin. Cada vez que se termina de procesar un registro de la tabla histrica de relaciones, esta estructura debe ser vaciada ya que el llegar a ese punto de la ejecucin indica que el registro procesado no sufri ningn problema. Siempre que el proceso de reubicacin termine de copiar un bloque, se debe agregar la referencia a ese bloque en esta estructura, esto es necesario para que al iniciar el sistema de ar chi vos se realice el rollback de estos cambios si hubo un error, es decir, los nuevo bloques van a ser marcados como libres. Esta tarea ser llevada a 49
cabo por el mdulo de rollback. 6.4.7. Co ntrol de la concurrencia
Dura nte la ejecucin del mdulo orquestador pueden ocurrir los siguientes escenarios que son potencialme nte peligrosos para la concurrencia: 1. Se ejecuta la reubicacin de algn archivo que est siendo utilizado por algn 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 ejecucin de cualquier registro (de la tabla histrica de relaciones) que tenga al menos 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 cuestin. 6.4.8. Mdulo de rollba ck
Este mdulo es el encargado de llevar a cabo la eliminacin de los ltimos cambios no aplicados. Al iniciar el sistema realizar el anlisis de la estructura que gura en la imagen 6.8, y en caso de ser necesario realiza el rollback. Como todos los mdulos, es ejecutado por el mdulo orquestado r. 6.4.9. Mdulo de depuracin de la tabla histrica de relaciones
Este mdulo debe llevar a cabo la tarea de depuracin de la tabla histrica de relaciones analiza en la seccin 6.3. El mdulo orquestador es el encargado de realizar la ejecucin del mdulo en cuestin. 6.4.10. Frecuencia de ejecucin del mdulo orquestador
El mdulo orquestador tiene tres funciones que son las siguientes: 1. Ejecutar el mdulo de rollba ck, esta ejecucin se efecta cuando inicia el sistema de archivos, es decir, este ejecutar el mdulo orquestador indicndole que realice la accin de rollba ck en cambios que no mantienen la consistencia. 2. Ejecutar el mdulo del principio de localidad en ar chi vos asociados, esta ejecucin se efecta en intervalos de un cierto tiempo que es un parmetro de con guracin del sistem a. Siempre que se intente ejecutar este mdulo se analizar si la cantidad de registros presentes en la cola de relaciones es mayor a un cierto parmetro del sistema. 3. Ejecutar el mdulo de depuracin de la tabla histrica de relaciones, esta ejecucin se efecta en el mismo intervalo que el mdulo del principio de localidad en archivos asociados, pero de manera intercalada con este.
50
6.5.
Modi caciones tcnica
necesarias
en Sistema
de ar chi vos NTFS para soportar esta
En esta seccin se describen las nuevas estructuras que son necesarias en un Sistema de archivos para soportar esta tcnica, adems 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 informacin sobre las nuevas relaciones generadas luego de que se ejecut el proceso de reubicacin de bloques, la estructura fsica que se plantea para la misma es un archivo con registros de longitud variable. El encabezado del archivo tiene la cantidad de registros presentes, este dato es analizado para determinar si se debe o no ejecutar el mdulo del principio de localidad en ar chi vos asociados. Cada registro del archivo est formado por un campo header, que tiene la longitud del campo siguiente campo que es el data, ste contiene las relaciones presentes en el registro.
51
6.5.2.
Tabla histrica
de relaciones ja, cada registro est
Para esta estructura se plantea utilizar un archivo formado por registros de longitud formado por los siguientes campos: Ide nti cador 1: Identi cador del primer archivo de la relacin. Ide nti cador 2: Identi cador del segundo archivo de la relacin.
Ca ntidad de repeticione s: Cantidad de repeticiones de la tupla de archivos relacionados.
6.5.3.
Estructura
utilizada
para ide nti cacin
de inconsistencias
tras una falla
Esta estructura est formada por tres campos que son los siguientes: Represe ntacin del comienzo de la transaccin. Nmero de registro de la tabla histrica de relaciones procesado. Represe ntacin del nal de la transaccin.
52
6.5.4.
Estructura
utilizada
para por el proceso de rollba ck
La organizacin planteada para esta estructura es un archivo de registros de longitud ja donde cada registro tiene una referencia a uno de los bloques que fueron copiados en el proceso de reubicacin de bloques.
53
6.5.5.
Modi caciones
generales
en los Sistemas
de archi vos
Las modi caciones generales que deben tener los sistemas de archivos para soportar la tcnica planteada en el presente trab ajo son las siguientes: Todas las nuevas estructuras planteadas en el punto anterior deben ser ubicadas en regiones de la unidad de almacenamie nto reservadas por el sistema de archivos para conocer su ubicacin 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 media nte su direccin fsica para marcarlo como libre en el proceso de rollba ck
54
7 EVALUACIN ANALTICA Y EXPERIMEN TAL DE LA PROPUES TA
7.
Evaluacin Analtica
y Ex perime ntal de la Propuesta
Cuando se accede a un archivo existen tres tiempos intervinie ntes en la operacin: 1. El tiempo que tardan los cabezales en posicionarse en el cilindro donde se encue ntra el sector a leer o escribir (tiem po de seek). 2. El tiempo de rotacin para que el sector a leer o escribir se encuentre con el cabeza l(tiem po de latencia). 3. El tiempo de lectura o escritura (tiem po de transferenci a).
7.1.
Evaluacin analtica
n n n S (n) u L (n) u T (n) 0 0
El tiempo de acceso a un archivo puede ser represe ntado con la siguiente expresin[20][21]: T =
Donde: El subndice n represe nta la cantidad de bloques que forman el archivo.

n 0
S(n) es la sumatoria de los tiem pos de seek generados por el acceso a todos los bloques que forman el
archivo.[20]
n 0
L(n) es la sumatoria de los tiem pos de latencia generados por el acceso a todos los bloques que forman
el archivo.[20]
n 0
T (n) es la sumatoria de los tiem pos de transferencia
generados por el acceso a todos los bloques que
forman el archivo.[20] 7.1.1. Hi ptesis sobre el tiem po de seek
Se plantea la siguiente hiptesis sobre el tiem po de see k, Yi N se cumple que S(i)=S(i + 1), es decir, dados dos cilindros cualquiera que sean consecutivos, el tiempo para trasladarse de uno al otro es el mismo. Bajo esta hiptesis se puede pensar en la siguiente expresin S (n) = Q abs (C (n) C (n 1)) donde Q es una consta nte que represe nta el tiempo en trasladarse de un cilindro a otro estando ambos ubicados de manera consecutiva. C (n) represe nta el nmero de cilindro en el que se encue ntra el bloque n, lo mismo aplica para la expresin C (n 1) .[21] 7.1.2. Hi ptesis sobre el tiem po de latencia
Se plantea la siguiente hiptesis sobre el tiem po de latenci a, 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 hiptesis se puede pensar en la siguiente expresin L (n) = M abs (B (n) B (n 1)) donde M es una consta nte que represe nta el tiempo en pasar de un bloque a otro estando ambos ubicados de manera consecutiva. B (n) represe nta el nmero de bloque fsico en el que se encue ntra el bloque n, lo mismo 55
7 EVALUACIN ANALTICA Y EXPERIMEN TAL DE LA PROPUES TA aplica para la expresin B (n 1) .[21]
56
7 EVALUACIN ANALTICA Y EXPERIMEN TAL DE LA PROPUES TA
7.1.3.
Hi ptesis sobre el tiem po de transferencia,
Planteando la siguiente hiptesis sobre el tiem po de transferenci a, Yi, j N se cumple que T (i)= T (j), es decir, que el tiempo de transferencia es el mismo para todos los bloques, se puede pensar en la siguiente expresin para represe ntar el tiempo de acceso a un archivo T =
n
S (n) u nK
L (n) u
donde K es una consta nte que represe nta el tiempo de transferencia de un bloque. Como nK sigue siendo una contante, la expresin se puede simpli car an ms[21] T = 7.1.4. Expresin
n 0
S (n) u
n 0
L (n) u K
general del tiem po de acceso
Teniendo en cuenta las hiptesis anteriores sobre los tres tiempos intervinie ntes en el acceso, el tiempo de acceso a un archivo se puede represe ntar con la siguiente expresin T =
n 0
Q abs (C (n) C (n 1)) u
n 0
M abs (B (n) B (n 1)) u K
siendo la expresin de nitiva[21] T =Q 7.1.5.

n 0
abs (C (n) C (n 1)) u M
n 0
abs (B (n) B (n 1)) u K entre cilindros
G co del tiem po de seek en funcin de la distancia r
Como se mencion, la expresin para represe ntar el tiempo de seek es S (n) = Q abs (C (n) C (n 1)) es una funcin de dos variables (Q es una consta nte), pero si se toma a C (n 1) como una consta nte P la expresin queda reducida a una funcin de una variable, es decir S (n) = Q abs (C (n) P ) esta expresin se puede utilizar para modelizar la variacin del tiempo de seek por el acceso a un bloque en relacin con el cilindro en el que se encue ntra el bloque accedido anteriorme nte (consta nte P). La expresin S (n) = Q abs (C (n) P ) es equivalente a la siguiente funcin partida { S (n) = Q (C (n) P ) si Q (P C (n)) si C (n) > P C (n) < P
57
El gr co anterior muestra la funcin S(n) para el caso en que P tenga el valor 5, el dominio de la funcin son todos los nmeros naturales. En l se oberva que S(n) crece de manera lineal con respecto a la separacin de los cilindros en los que se encue ntran los bloques.[21] Cabe hacer la aclaracin de que el valor 5 es a modo de ejempli cacin. 7.1.6. G co del tiem po de latencia r en funcin de la distancia entre bl oques
Como se mencion, la expresin para represe ntar el tiempo de latencia es L (n) = M abs (B (n) B (n 1)) es una funcin de dos variables (M es una consta nte), pero si se toma a B (n 1) como una consta nte Z la expresin queda reducida a una funcin de una variable, es decir L (n) = M abs (B (n) Z ) esta expresin se puede utilizar para modelizar la variacin del tiempo de latencia en relacin con la posicin del bloque accedido anteriorme nte (consta nte P) independie nteme nte del cilindro en el que se encuentren. La expresin L (n) = M abs (B (n) Z ) es equivalente a la siguiente funcin partida { L (n) = M (B (n) Z ) si M (Z B (n)) si B (n) > Z B (n) < Z
El gr co anterior muestra la funcin L(n) para el caso en que Z tenga el valor 5, el dominio de la funcin son todos los nmeros naturales. En l se oberva que L(n) crece de manera lineal con respecto a la separacin de los bloques(inde pendie nteme nte de los cilindros en los que se encue ntren).[21] Cabe hacer la aclaracin de que el valor 5 es a modo de ejempli cacin. El gr co anterior y el que represe nta el tiempo de seek en funcin de la distancia entre cilindros(7.1.5) no tienen por qu tener la misma pendiente ya que los valores Q y M pueden no qu ser iguales (son las pendientes de las rectas) . 7.1.7. Obser vaciones nales sobre el tiem po de acceso
La expresin nal del tiempo de acceso a un archivo es T =Q

n 0
abs (C (n) C (n 1)) u M
n 0
abs (B (n) B (n 1)) u K
por lo tanto la nica va para reducir este tiempo es reducir las distancias fsicas entre los bloques que forman el archivo, cuanto ms cercanos estn los bloques ms se reducir el tiempo de accceso, siendo el caso ptimo ubicar todos los bloques de manera consecutiva en el mismo cilindro de la unidad de almacenamie nto.
7.2.
7.2.1.
Evaluacin Ex perime ntal

Descri pcin de la simulacin
La evaluacin prctica se basa en la simulacin de los accesos a diferentes archivos efectuados por los procesos en un sistema de archivos. Para esto se realizaron varios mdulos que interactan entre si y son descriptos a continuacin: Mdulo FileSystem: Encargado de ejecutar los accesos para cada uno de los procesos con gurados. Este mdulo genera la informacin de las relaciones de archivos (principio de localidad basado en relaciones) y los tiempos de acceso a los mismos.
Mdulo Locali tyPrinciple: Accede a la cola de relaciones respeta el algoritmo prese ntado en la seccin 6.1.1
y genera un resultado
tem poral que
Mdulo Merge: Accede a la tabla histrica de relaciones y al resultado temporal generado por el mdulo Locali tyPrinciple y realiza el merge entre ambas respetando lo planteado en la seccin 6.1.1 Mdulo Rel ocation: relaciones . Mdulo Or chestrator: tion. Mdulo Con gurations: Mdulo Statics: Realiza la reubicacin de bloques respetando el principio Realiza la orquestacin de los mdulos Locali tyPrinciple, de localidad segn Merge y Rel oca-
Encargado de acceder a las diferentes con guraciones de la simulacin.
Encargado de persistir las estadsticas obtenidas.
La simulacin se basa en la ejecucin de los procesos, cada uno de estos realiza una serie de accesos a archivos, los procesos se crean a partir de una con guracin, en ella adems, por cada proceso, se especi ca una lista de archivos a los que debe acceder, a continuacin se ejempli ca la con guracin de procesos: process.count=2 process.id.0=123 process.access.0=30,RANDOM,9000|1001,SEQUENTIAL,500 process.id.1=321 process.access.1=31,RANDOM,9000| 2100,RANDOM,8777 Esta con guracin indica que se deben ejecutar dos procesos, el primer proceso tiene id 123, realiza el acceso a dos archi vos, el primer acceso realizado es al archi vo 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 manera aleatoria a cualquier de sus bloques, el acceso secuencial implica acceder de manera coonsecutiva a los bloques del archivo comenzando desde el primero, en caso de que se ejecuten ms accesos que bloques tiene el archivo se vuelve a comenzar desde el primer bloque. Los archivos existentes en el sistema de archivos simulado se crean a partir de la siguiente con guracin: les.cou nt=2 le.id.0=30 le.bl ocks.0=1001,9000|1001,9001|1001,9002 le.id.1=31 le.bl ocks.1=2100,9000|2100,9001|2100,9002|2100,9003|2100,9020|2100,9022 Esta con guracin indica que existen dos archivos, el primero id 30, y est compuesto por tres bl oques, el primero de ellos se encue ntra en el cilindro 1001 y en la pista 900 0. La cantidad de cilindros y cantidad de bloques por cilindro que tendr la unidad de almacenamie nto simulada (sobre la que se ejecuta el sistema de archivos simulado) se crea a partir de la siguiente con guracin: tracks.cou nt=5000 bloks. by.tra cks=10000 Esta con guracin indica que la unidad de almecenamie nto tiene 5000 cilindros por cilindr o. (o pistas) y 10000 bloques
El mdulo FileSystem recibe estas con guraciones y en base a ellas realiza la ejecucin de todos los procesos y para cada uno de ellos todos sus accesos a los archivos que tiene con gurado, se mide el tiempo en que cada proceso realiza el acceso a todos los archivos, este dato ser persistido por el mdulo de estadsticas luego. Este proceso se repite dos veces, entre ella se ejecuta el mdulo Or chestrator localidad platenado en la seccin 6.1.1 para aplicar el principio de
Se tomarn las estadsticas 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 modelizacin de los mismos, se le asignar un peso a cada cilindro y a cada bloque recorrido para acceder al prximo bloque, por lo tanto los tiempos se miden en funcin de estos pesos, por ejemplo, si el bloque n est ubicado en la tupla (10, 200) (nro. de cilindro ms nro. de bloque), y el bloque n+1 est ubicado en la tupla (11, 250), el tiempo para realizar 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 simulacin
7.2.3.
Diagrama
de secuencia
de la simulacin
7.2.4.
Cdigo fue nte de mdulo FileSystem
package t esis . core . filesyst em .impl;
import java . ut il . ArrayList ;import java . ut il . Collect i ons ;import java . ut il . List ; i m p o r t j a v a . u t i l . Map ; import org.apache. log4j .Logger ; import org . springframework . beans. fact ory . annotation . Required ; import import import import import import import t t t t t t t esis esis esis esis esis esis esis . . . . . . . core core core core core core core . filesyst em . FileSystem ; . filesyst em . resolver . BlockSelectorResolver ; . filesyst em . resolver . st rat egies . BlockSelector ; . filesyst em . resolver . st rat egies .model. BlockSelectorData ; .model. files .Block ; .model. process . Access; .model. relat ionshipsqueue . RelationshipsQueue ;
public class FileSystemImpl implements FileSystem{ final st at ic Logger L G E R= Logger . getLogger(FileSystemImpl. class) ; OG
privat e BlockSelectorResolver blockSelect orReso lver ; privat e Block currentHeadBlock = null ;// Current block of head p u b l i c L i s t <Lon g> e x e c u t e ( t e s i s . c o r e . m o d e l . f i l e s y s t e m . F i l e S y s t e m f i l e S y s t e m , L i s t < t e s i s . c o r e . m o d e l . p r o c e s s . P r o c e s s > p r o c e s s , Map<Long , L i s t > f i l e s , R e l a t i o n s h i p s Q u e u e r e l a t i o n s h i p s Q u e u e ) { L i s t <Lon g> a c c e s T i m e s = new A r r a y L i s t <Long >(); int executionsCount = fileSyst em . getExecutionsCount () ; f o r ( i n t i = 0 ; i < e x e c u t i o n s C o u n t ; i + ){ + for ( t esis . core .model. process . Process proc : process) { L i s t <Lon g> r e l a t i o n s h i p s F i l e = new A r r a y L i s t <Long > ( ) ; Map<Long , L i s t <Lon g>> r e l a t i o n s h i p s = r e l a t i o n s h i p s Q u e u e . g e t R e l a t i o n s h i p s ( ) ; if ( relat ionships . containsKey(proc. getId () )){ relat ionshipsFile .addAll( relat ionships . get (proc. getId () )) ; } processAllAccess(proc. getAccess() , accesTimes , files , relat ionshipsF ile) ;
if (! relat ionships . containsKey(proc. getId () )){ relat ionships .put (proc. getId () , relat ionshipsFile ) ; }else{ insertNotRepeatFilesId ( relat ionships . get (proc. getId () ) , relat ionshipsF il e); } Collect ions . sort ( relat ionships . get (proc. getId () )) ; L G E R. d e b u g ( " P r o c e s i n g p r o c e s s " . c o n c a t ( Long . t o S t r i n g ( p r o c . g e t I OG d () )) .concat (" of it erat ion ") . concat ( Int eger . toString( i))) ; } } return accesTimes; } p r i v a t e v o i d i n s e r t N o t R e p e a t F i l e s I d ( L i s t <Lon g> r e l a t i o n s h i p s , L i s t <Lon g> r e l a t i o n s h i p s F i le) { 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 ) { if (! relat ionships . contains( fileId )){ r e l a t i o n s h i p s . add ( f i l e I d ) ; } } } p r i v a t e v o i d p r o c e s s A l l A c c e s s ( L i s t <A c c e s s > a c c e s s , L i s t <Lon g> a c c e s T i m e s , Map<Long , L i s t > f i l e s , L i s t <Lon g> r e l a t i o n s h i p s F i les ) {
long time = 0; for (Access acc : access) {
time = time + getAccessTime(acc ,
files ) ;
i f ( r e l a t i o n s h i p s F i A n l i s i s d e l o s r e s u l t a d o s l e s . i n d e x O f ( a c c . g e t F 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 ( a c c . g e t F i l e I d ( ) ) ; } } a c c e s T i m e s . add ( Long . v a l u e O f ( t i m e ) ) ; } p r i v a t e l o n g g e t A c c e s s T i m e ( A c c e s s a c c e s s , Map<Long , L i s t > f i l e s ) { long time = 0; L i s t b l o c k s = f i l e s . g e t ( a c c e s s . g e t F i l e I d ( ) ) ; i f ( b l o c k s != n u l l ) { B l o c k S e l e c t o r D a t a b l o c k S e l e c t o r D a t a = new B l o c k S e l e c t o r D a t a ( t his .currentHeadBlock , blocks) ; BlockSelector pe() ) ; blockSelect or = blockSelect orResolver . resolve( access . getAccessTy
int accessCount = access . getAccessCount () ; f o r ( i n t i = 0 ; i < a c c e s s C o u n t ; i + ){ + Block toBlock = blockSelect or . select (blockSelectorData ) ; time = time + TimesHelper . getTraslationTime( t his .currentHeadBlock , toBloc k); t his .currentHeadBlock = toBlock ; blockSelectorData . setCurrentBlock( t his .currentHeadBlock) ; } } return time; } @Required public void set BlockSelect orResolver ( BlockSelectorResolver t his . blockSelect orResolver = blockSelect orResolver ; } } blockSelect orResolver ) {
7.2.5.
Cdigo fue nte de mdulo TimesHel per
package t esis . core . filesyst emAnlisis de los result ados .impl; import t esis . core .model. files .Block ; public class TimesHelper { p r i v a t e f i n a l s t a t i c i n t FIRST_GLOBAL_ACCESS_TIME = 0 ; p r i v a t e f i n a l s t a t i c i n t CHAN GE_TRACK_TIME = 10;privat e final st at ic int CHANGE_BLOCK_TIME = 1 ; public st at ic long getTraslationTime(Block fromBlock , Block toBlock){ i f ( f r o m B l o c k == n u l l ) { / / i s t h e f i r s t g l o b a l a c c e s s r e t u r n FIRST_GLOBAL_ACCESS_TIME ; } i n t d i f f e r e n c e T r a c k s = Math . a b s ( f r o m B l o c k . g e t T r a c k N u m b e r ( ) t o B l o c k . g e t T r a c k N u m ber() ) ; l o n g d i f f e r e n c e B l o c k s = Math . a b s ( f r o m B l o c k . g e t B l o c k N u m b e r ( ) t o B l o c k . g e t B l o c k N u mber() ) ; r e t u r n ( d i f f e r e n c e T r a c k s CHANGE_TRACK_TIME) + ( d i f f e r e n c e B l o c k s CHANGE_BLOCK_TIME) ; } }
7.2.6.
Cdigo fue nte de mdulo Locali tyPrinciple
package t esis . core . localit yprinciple .impl; import java . ut il . ArrayList ;
import java . ut il . Collect ions ; import java . ut il . List ; i m p o r t j a v a . u t i l . Map . E n t r y ; import org.apache. log4j .Logger ; import t esis . core . localit yprinciple . Localit yP rinciple ; import t esis . core . localit yprinciple .model. BasicRelationsh ip ;import t esis . core .model. localit yprinciple .TemporaryRe sult ;import t esis . core .model. relat ionshipsqueue . Relations hipsQueue ;import tesis . core .model. relat ionshist oryt able . Relationship ; public class Localit yP rincipleImpl implements Localit yP rinciple{ final st at ic Logger L G E R= Logger . getLogger( Localit yP rincipleImpl . OG class) ;
public TemporaryResult execute(RelationshipsQueue relationshipsQ u e u e ) { L i s t <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 = new A r r a y L i s t <R e l a t i o n s h i p > ( ) ; L i s t b a s i c R e l a t i o n s h i p s ; Relationship relationshipTmp ; int it erat ionIndex = 1; f o r ( E n t r y<Long , L i s t <Lon g>> r e l a t i o n s h i p Q u e u e : r e l a t i o n s h i p s Q u e u e . g e t R e l a t i o n s hips () .entrySet () ) { L i s t <Lon g> f i l e s I d = r e l a t i o n s h i p Q u e u e . g e t V a l u e ( ) ; if ( filesId . size () > 1){ basicRelat ionships = CartesianProductHelper . getCartesianProduct ( filesId ) ; for ( BasicRelationship basicRelat ionship : basicRelat ionships) { r e l a t i o n s h i p T m p=ne w R e l a t i o n s h i p ( b a s i c R e l a t i o n s h i p . g e t F i r s t F i l eId () ,basicRelat ionship . getSecondFileId () , 1) ; int index = relat ionships .indexOf(relationshipTmp) ; i f ( i n d e x == 1) { r e l a t i o n s h i p s . add ( r e l a t i o n s h i p T m p ) ; }else{ Relationship relat ionship = relat ionships . get (index) ; relat ionship . setRepetitionsCount ( relat ionship . getRepetitionsCount () +1 ) ; } } } it erat ionIndex = it erat ionIndex + 1; } Collect ions . sort ( relat ionships) ; r e t u r n new T e m p o r a r y R e s u l t ( r e l a t i o n s h i p s ) ; } }
7.2.7.
Cdigo fue nte de mdulo CartesianPr
oductHel per
package t esis . core . localit yprinciple .impl; import java . ut il . ArrayList ; import java . ut il . List ; import t esis . core . localit yprinciple .model. BasicRelationship ; public class CartesianProductHelper { p u b l i c s t a t i c L i s t g e t C a r t e s i a n P r o d u c t ( L i s t <Lon g> f i l e s I d ) { L i s t c a r t e s i a n P r o d u c t = new A r r a y L i s t () ; BasicRelationship basicRelationshipTmpOne; BasicRelationship basicRelationshipTm pTwo;
f o r ( Long
fileId
filesId ) {
f o r ( Long f i l e I d T m p : f i l e s I d ) { i f ( f i l e I d != f i l e I d T m p ) { b a s i c R e l a t i o n s h i p T m p O n e = new B a s i c R e l a t i o n s h i p ( f i l e I d , f i l e I d T m p ) ; b a s i c R e l a t i o n s h i p T m p T w o = new B a s i c R e l a t i o n s h i p ( f i l e I d T mp , fileId ) ;if (!cartesianProduct . contains(basicRelationshipTm p O n e ) && !cartesianProduct . contains(basicRelationshipTmpTwo)){ c a r t e s i a n P r o d u c t . add ( b a s i c R e l a t i o n s h i p T m p O n e ) ; } } } return } } cartesianProduct ;
7.2.8.
Cdigo fue nte de mdulo Merge
package t esis . core .merge.impl; import java . ut il . ArrayList ;import java . ut il . Collect i ons ;import java . ut il . List ; import import import import t t t t esis esis esis esis . . . . core core core core . m e r g e . Merge ; . m o d e l . l o c a l i t y p r i n c i p l e . T e m p o r a r y R e s u l t; .model. relat ionshist oryt able . RelationsHistoryTable ; .model. relat ionshist oryt able . Relationship ;
p u b l i c c l a s s M e r g e I m p l i m p l e m e n t s Merge { final st at ic Logger L G E R= Logger . getLogger(MergeImpl. class) ; OG
public RelationsHistoryTable execute( RelationsHistoryTable relationsHistor yTable ,TemporaryResult temporaryResult ) { L i s t <R e l a t i o n s h i p > r e l a t i o n s H i s t o r y = new A r r a y L i s t <R e l a t i o n s h i p > ( ) ; copyRelationsHistoryTable( relationsHistoryTable , relat ionsHist ory ) ;
i f ( t e m p o r a r y R e s u l t == n u l l | | t e m p o r a r y R e s u l t . g e t R e l a t i o n s h i p s ( ) == n u l l ) { r e t u r n new R e l a t i o n s H i s t o r y T a b l e ( r e l a t i o n s H i s t o r y ) ; } L G E R. d e b u g ( " C a l l i n g a d d T e m p o r a r y R e s u l t method " ) ; OG addTemporaryResult (temporaryResult , relat ionsHist ory ) ; L G E R. d e b u g ( " S o r t i n g c o l l e c t i o n OG ") ;Collect ions . sort ( relat ionsHis t ory ) ; r e t u r n new R e l a t i o n s H i s t o r y T a b l e ( r e l a t i o n s H i s t o r y ) ; } privat e void copyRelationsHistoryTable( RelationsHistoryTable relationsHistor y T a b l e , L i s t <R e l a t i o n s h i p > r e l a t i o n s H i s t o r y ) { i f ( r e l a t i o n s H i s t o r y T a b l e != n u l l && r e l a t i o n s H i s t o r y T a b l e . g e t R e l a t i o n s h i p s ( ) != n u l l) { for ( Relationship relat ionship : relat ionsHist oryTable . get Relat ionships () ) { r e l a t i o n s H i s t o r y . add ( new R e l a t i o n s h i p ( 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 ( ) , relationship . getSecondFileId () , relat ionship . getRepetitionsCoun t () )) ; } } } privat e void addTemporaryResult (TemporaryResult temporar y R e s u l t , L i s t <R e l a t i o n s h i p > r e l a t i o n s H i s t o r y ) { int index ; Relationship relationshipTmp ;
for ( Relationship relat ionship : temporaryResult . get Relat ionships () ) { i n d e x= r e l a t i o n s H i s t o r y . i n d e x O f ( r e l a t i o n s h i p ) ; i f ( i n d e x != 1) {
r e l a t i o n s h i p T m p= r e l a t i o n s H i s t o r y . g e t ( i n d e x ) ; relationshipTmp . setRepetitionsCount (relationshipTmp . getRepetitionsCount () + relat ionship . getRepetitionsCount ( )); } else{ r e l a t i o n s H i s t o r y . add ( r e l a t i o n s h i p ) ; } } } }
7.2.9.
Cdigo fue nte de mdulo Rel ocation
package t esis . core . relocat ion .impl; import java . ut il . ArrayList ;i m p o r t j a v a . u t i l . LinkedHashMa p ;import java . ut il . List ; i m p o r t j a v a . u t i l . Map ; i m p o r t j a v a . u t i l . Map . E n t r y ; import org.apache. log4j .Logger ; import import import import import t t t t t esis esis esis esis esis . . . . . core core core core core .model. files .Block ; .model. filesyst em . BlockStatus; .model. relat ionshist oryt able . RelationsHistoryTable ; .model. relat ionshist oryt able . Relationship ; . relocat ion . Relocation ;
public class RelocationImpl implements Relocation{ final st at ic Logger LG E R= Logger . getLogger(RelocationImpl . class) ; OG
public void execute( RelationsHistoryTable relationsHistoryTable , Map<Long , L i s t > f i l e s , LinkedHashMap s t a t u s B l o c k s ) { L G E R. d e b u g ( " g e t O p t i m a l F i l e s O r d e r method " ) ; OG L i s t <Lon g> o p t i m a l F i l e s O r d e r = g e t O p t i m a l F i l e s O r d e r ( r e l a t i o n s H i s t o r y Table .get Relat ionships () ) ; L G E R. d e b u g ( " g e t O p t i m a l B l o c k s O r d e r method " ) ; OG L i s t o p t i m a l B l o c k s O r d e r = g e t O p t i m a l B l o c k s O r d e r ( o p t i m a l F i l e s O r d e r , ; L G E R. d e b u g ( " r e l o c a t i o n B l o c k s method " ) ; OG relocat ionBlocks(optimalBlocksOrder , statusBlocks) ; } p r i v a t e L i s t <Lon g> g e t O p t i m a l F i l e s O r d e r ( L i s t <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 ) { L i s t <Lon g> o p t i m a l F i l e s O r d e r = new A r r a y L i s t <Long > ( ) ; for ( Relationship relat ionship : relat ionships) { if (!optimalFilesOrder . contains( relat ionship . get First FileId () )){ o p t i m a l F i l e s O r d e r . 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 ( ) ) ; } if (!optimalFilesOrder . contains( relat ionship . getSecondFileId () )){ o p t i m a l F i l e s O r d e r . add ( r e l a t i o n s h i p . g e t S e c o n d F i l e I d ( ) ) ; } } return optimalFilesOrder ; } p r i v a t e L i s t g e t O p t i m a l B l o c k s O r d e r ( L i s t <Lon g> o p t i m a l F i l e s O r d e r , Map<Long , L i s t > f i l e s ) { L i s t o p t i m a l B l o c k s O r d e r = new A r r a y L i s t ( ) ; f o r ( Long f i l e I d : o p t i m a l F i l e s O r d e r ) { L G E R. d e b u g ( " method g e t O p t i m a l B l o c k s O r d e r , OG Id " file files )
. c o n c a t ( Long . v a l u e O f ( f i l e I d ) . t o S t r i n g ( ) ));
optimalBlocksOrder . addAll( files . get ( fileId )) ; } return optimalBlocksOrder ; } p r i v a t e v o i d r e l o c a t i o n B l o c k s ( L i s t o p t i m a l B l o c k s O r d e r , LinkedHashMap s t a t u s B l o c k s) { i f ( o p t i m a l B l o c k s O r d e r . s i z e ( ) == 0 ) { return ; } int currentBlockIndex = 0;Block currentBlock ; f o r ( E n t r y b l o c k : s t a t u s B l o c k s . e n t r y S e t ( ) ) { i f ( b l o c k . g e t V a l u e ( ) == B l o c k S t a t u s . FRE E) { currentBlock = optimalBlocksOrder . get (currentBlockIndex) ; currentBlock .setBlockNumber(block .getKey() .getBlockNumber() ) ; currentBlock .setTrackNumber(block .getKey() .getTrackNumber() ) ; i f ( o p t i m a l B l o c k s O r d e r . s i z e ( ) 1 == c u r r e n t B l o c k I n d e x ) { return ; } currentBlockIndex = currentBlockIndex + 1; } } } }
7.2.10.
Cdigo fue nte de mdulo Or chestrator
package t esis . core . orchest rat or .impl; i m p o r t j a v a . u t i l . LinkedHashMa p ; import java . ut il . List ; i m p o r t j a v a . u t i l . Map ; import org . springframework . beans. fact ory . annotation . Required ; import import import import import import import import import t t t t t t t t t esis esis esis esis esis esis esis esis esis . . . . . . . . . core core core core core core core core core . localit yprinciple . Localit yP rinciple ; . m e r g e . Merge ; .model. files .Block ; .model. filesyst em . BlockStatus; . m o d e l . l o c a l i t y p r i n c i p l e . T e m p o r a r y R e s u l t; .model. relat ionshipsqueue . RelationshipsQueue ; .model. relat ionshist oryt able . RelationsHistoryTable ; . orchest rat or . Orchestrator ; . relocat ion . Relocation ;
public class OrchestratorImpl implements Orchestr ator{privat e Localit yP rinciple l e ; p r i v a t e Merge m e r g e ; privat e Relocation n ; relocat io localit yPrincip
public void execute(RelationshipsQueue relationshipsQueue , RelationsHis t o r y T a b l e r e l a t i o n s H i s t o r y T a b l e , Map<Long , L i s t > f i l e s , LinkedHashMap s t a t u s B l o c k s ) { TemporaryResult temporaryResult = t his . localit yP rinciple . execute( relationshipsQue ue) ; relat ionsHist oryTable . set Relat ionships( t his .merge. execute( relationsHistor yTable ,temporaryResult ) . get Relat ionships () ) ; t his . relocat ion . execute( relationsHistoryTable , files , statusBlocks) ;
@Required public void set Localit yP rinciple( Localit yP rinciple t his . localit yP rinciple = localit yP rinciple ; } @Required p u b l i c v o i d s e t M e r g e ( Merge m e r g e ) { t his .merge = merge; } @Required public void set Relocat ion (Relocation t his . relocat ion = relocat ion ; } } relocat ion ) {
localit yPrinciple) {
7.2.11.
Cdigo fue nte de mdulo RandomBl ockSelector
package t esis . core . filesyst em . resolver . st rat egies .impl; import java . ut il . List ; i m p o r t j a v a . u t i l . Rando m ; import import import import import org.apache. log4j .Logger ; org. springframework . ut il . Collect ionUt ils ; t esis . core . filesyst em . resolver . st rat egies . BlockSelector ; t esis . core . filesyst em . resolver . st rat egies .model. BlockSelectorData ; t esis . core .model. files .Block ;
public class RandomBlockSelector implements BlockSelector{ final st at ic Logger L G E R= Logger . getLogger(RandomBlockSelector . class) ; OG
public Block select (BlockSelectorData blockSelectorD a t a ) { L i s t b l o c k s = b l o c k S e l e c t o r D a t a . g e t Blocks() ; if( Collect ionUt ils .isEmpty( blocks)){ return null ; } Rando m r a n d o m G e n e r a t o r = new Rando m ( ) ; int index = randomGenerator . nextInt ( blocks . siz e () ) ;Block block = blocks . get (index) ; L G E R. d e b u g ( S t r i n g . f o r m a t ( " i n d e x s OG i return block ; } } 1 for %s " , b l o c k ) ) ;
7.2.12.
Cdigo fue nte de mdulo Secue ntialBl ockSelector
package t esis . core . filesyst em . resolver . st rat egies .impl; import java . ut il . List ; import org.apache. log4j .Logger ; import org. springframework . ut il . Collect ionUt ils ; import t esis . core . filesyst em . resolver . st rat egies . BlockSelector ; import t esis . core . filesyst em . resolver . st rat egies .model. BlockSelectorData ; import t esis . core .model. files .Block ; public class Secuent ialBlockSelect or implements BlockSelector{ final st at ic Logger L G E R= Logger . getLogger( Secuent ialBlockSelect or . class) ; OG
public Block select (BlockSelectorData blockSelectorData ) { Block currentBlock = blockSelectorData . getCurren t B l o c k ( ) ; L i s t b l o c k s = b l o c k S e l e c t o r D a t a . g e t Blocks() ; if( Collect ionUt ils .isEmpty(blocks ) ) { L G E R. d e b u g ( " empty l i s t a " ) OG ;return null ; } i f ( c u r r e n t B l o c k == n u l l ) { L G E R. d e b u g ( " c u r r e n t B l o c k OG return blocks . get (0) ; } is null") ;
int index = blocks .indexOf(currentBloc k); i f ( i n d e x == 1) { 1 for L G E R. d e b u g ( S t r i n g . f o r m a t ( " i n d e x i s OG return blocks . get (0) ; } index = index + 1; i f ( i n d e x == b l o c k s . s i z e ( ) ) { / / End o f c o l l e c t i o n s L G E R. d e b u g ( S t r i n g . f o r m a t ( " l a s t b l o c k o f c o l l e c t i o n OG return blocks . get (0) ; } return } } blocks . get (index) ; for %s " , c u r r e n t B l o c k ) ) ; %s " , c u r r e n t B l o c k ) ) ;
7.2.13.
Anlisis comparati vos de los resultados
Para la simulacin se utiliz una unidad de almacenamie nto con las siguientes caractersticas: 1. Formada por 20 pistas. 2. Formada por 1000 bloques por pista. 3. Formada por un total de 20000 bloques disponibles. Adems cada set de procesos se ejecut 3 veces para obtener una cantidad mayor de valores para analizar. El set de prueba de archivos se prese nta a continuacin : Cantidad de archivos Cantidad de bloques utilizados Porce ntaje bloques utilizados 50 archivos 1353 bloques 6,76 100 archivos 2436 bloques 12,18 200 archivos 4399 bloques 21,99 300 archivos 11162 bloques 55,81 400 archivos 8099 bloques 40,49
El set de prueba de procesos se prese nta a continuacin :
Cantidad de procesos 50 archivos accedidos
100 archivos accedidos
2500 procesos 5476 accesos a archivos. 1358105 bloques accedidos. 11583 accesos a archivos. 2884391 bloques accedidos. 23816 accesos a archivos. 5932471 bloques accedidos. 36249 accesos a archivos. 9052319 bloques accedidos. 48084 accesos a archivos. 11988251 bloques accedidos.
Se generar un set de datos que represe nte diferentes cargas de bloques de la unidad de almacenamie nto, as como diferentes cantidades de procesos que realizan accesos, el n es obtener resultados para diferentes escenarios y poder analizar los resultados obtenidos.
Ejecucin
de 2500 pr ocesos: nto:
50 archi vos en la unidad de almacenamie
100 ar chi vos en la unidad de almacenamie
nto:
nto:
nto:
nto:
Ejecucin
de 5000 pr ocesos:
nto:
[20]
nto:
[20]
nto:
nto:
nto:
Ejecucin
de 7500 pr ocesos: nto:
nto:
nto:
nto:
nto:
7.2.14.
Resumen
de los resultados
obtenidos
A continuacin se exponen tablas que represe ntan las mejoras obtenidas media nte la aplicacin de la nueva poltica de relaciones basadas en el principio de localidad:
Ejecucin
de 2500 pr ocesos: 50 754407 0 91718 0 198658 4508 100 1343284 0 530552 0 410071 12895 200 2320207 34 320076 21 830637 29398 300 3320462 148 1702167 78 1245163 386769 400 4363136 145 497255 97 1660935 64892
Cantidad de archivos Mximo tiempo sin la nueva poltica Mnimo tiempo sin la nueva poltica Mximo tiempo con la nueva poltica Mnimo tiempo con la nueva poltica Promedio de tiempos sin la nueva poltica Promedio de tiempos con la nueva poltica
Ejecucin
de 5000 pr ocesos: 50 861724 0 61859 0 200608 4279 100 1336700 0 198041 0 408889 10207 200 2486845 131 516509 9 842112 29771 300 3569687 88 1725089 40 1243215 316781 400 4728537 4 687140 7 1699897 65648
Ejecucin
de 7500 pr ocesos: 50 792046 0 289047 0 201702 6377 100 1352103 0 377313 0 410659 12447 200 2474311 0 400625 0 831121 29116 300 3378486 0 1781838 0 1239354 422841 400 4430167 0 610270 0 1696820 68845
En todos los casos el promedio de los tiempos de acceso se reduce considerableme nte, adems se observa en los gr cos de la seccin anterior que la distribucin de tiempos de acceso tiende a consolidarse en los valores ms bajos, cuando sin aplicar el proceso de relaciones por el principio de localidad la distribucin de los tiempos estaba dispersa sobre todos los tiempos posibles.
8 CONCLUSIN
8.
8.1.
Conclusin
Anlisis de los resultados
En este trab ajo se present una nueva poltica para la administracin de los bloques pertenecie ntes a los archivos, la misma se basa en relacionar todos los archivos accedidos por el mismo proceso. El objetivo de esta nueva poltica es mejorar los tiempos de acceso, para esto se reubican los bloques de los archivos respetando el principio de localidad de archi vos asociado s. Se efectu un anlisis cualtitati vo para analizar el impacto de esta tcnica con respecto a la no impleme ntacin de la misma, los resultados obtenidos arrojaron que la impleme ntacin de la misma reduce en gran medida los tiempos de acceso a los archivos. Quedan planteados trabajos a futuro para mejorar la performance de esta tcnica e investigar los campos de aplicacin en los que mejores resultados se obtienen, en especial, el estudio de nuevas polticas de reubicacin de los bloques (siempre respetando las relaciones de los archivos segn la tcnica aqu planteada). Se analizaron varios trab ajos de investigacin sobre problemas para atacar en los sistemas de archivos, el campo de investigacin es muy grande.
8 CONCLUSIN
8.2.
Trab ajos futuros
Como trab ajos futuros se proponen los siguientes temas: 1. Investigar alternati vas para obtener una buena poltica de reubicacin de bloques. 2. Investigar alternati vas de mecanismos de log para recuperar la consistencia en el momento de una falla del sistema. 3. Investigar tcnicas para controlar la concurrencia en las estructuras que utiliza la tcnica planteada. 4. Analizar opciones para el intervalo de ejecucin del mdulo orquestador. 5. Analizar entornos en los que mejor aplica esta tcnica. La aplicacin de una buena tcnica de reubicacin de bloques es muy importa nte para increme ntar la performance de la tcnica, mientras la reubicacin se realice de manera ms intelige nte, menores van a ser los tiempos de acceso. La concurrencia debe ser investigada para dar respuesta a detalles como el siguiente, qu poltica tomar cuando se intenta acceder a un archivo que est siendo reubicado? Un tema muy interesa nte para abordar es la investigacin de los campos espec cos en los que la aplicacin de esta tcnica increme nta en mayor medida la performance, por ejemplo, servidores dedicados a la ejecucin de pocos procesos, como un servidor de base de datos, puede tener una mejor performance que una computadora hogarea ya que los pocos procesos acceden a los mismos archivos, en cambio en la computadora hogarea segurame nte ocurra lo contrario. La investigacin y posterior impleme ntacin de estos trab ajos futuros van a generar que la tcnica sea ms segura y ms efectiva. Como se observa, el campo de investigacin es muy mplio.
10 REFERENCIAS
10.
Referencias
[1]Andrew S. Tanenbaum. Sistemas operativos modernos. [2]Apuntes de la materia organizacin de datos. [3]http://www.tldp.org/H OWTO/Filesystems-H OWTO-7. html#hfs ocume ntation/mac/More Toolb ox/More Toolb ox-11. html
[4]http://de velop er.apple.com/legacy/mac/library/d [5]http://pages.cs.wisc.edu/~legault/minipr
o j-736. pdf
[6]http:// kernelnewbies.org/Ext4#head-38e6ac2b5f58f10989d72386e6f9cc2ef7217fb0 [7]http://www.ibm.com/de velop erworks/li nux/library/l-ext4/ muni ty+Group+zfs/d ocs
[8]http:// hub.o pensolaris.org/bin/view/Com [9]http://www.ibm.com/de
velop erworks/li nux/library/l-anato my-ext4/ px
[10]http://te chnet.microsoft.com/en-us/library/cc778290(WS.10).as
[11] Johns Hopkings universi ty , Ext3cow: A Time-Shifting File System for Regulatory Compliance http://hssl.cs.j hu.edu/~za chary/pa pers/ peterson-tos05. pdf [12] A Fast File System for UNIX, universi ty of California http://www.cs. berkeley.edu/~bre wer/cs262/FFS. pdf [13]"Intellige nt methods for le system optimization, Leo Kuvayev university of Massa chusetts" http://clgiles.ist.psu.edu/pa pers/AAAI-97.i ntellige nt. le.organization. pdf [14]"Ext4, btrfs, and the others, Jan Kra" http://atre y.karlin.m .cuni.cz/~ja ck/pa pers/lk2009-ext4-btrfs. pdf [15]"The new ext4 lesystem: curre nt status and future plans, IBM Linux Technology Center" http:// kernel.org/d oc/ols/2007/ols2007v2-pages-21-34. pdf [16] The e ects of age and fragme ntation on le system performance, Harvard universi ty http://www.eecs.har vard.edu/~ keith/resear ch/tr94. html [17] Design algorithms for asynchronous write operations in disk-bu er-ca che memory, AT&T Bell Laboratories, Naperville, Illinois, USA [18] A Better Update Policy, Je rey C. Mogul, Digital Equipme nt Corporation Western Research Laboratory [19] The MultiQueue replaceme nt algorithm for second level bu er caches, Yuanyuan Zhou and James F. Philbin, Princeton universi ty [20] Average seek time of a computer disk , Computer Science

Sistemas de Archivos: Propuesta para optimizar el rendimiento mediante la localidad de archivos asociados

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sistemas de Archivos: Propuesta para optimizar el rendimiento mediante la localidad de archivos asociados

Uploaded by

Copyright:

Available Formats

UNIVERSIDADNACIONALDEPIURA FACULTADDEINGENIERAINDUSTRIAL ESCUELAPROFESIONALDEINGENIERAINFORMTICA

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4. Rele vamie nto bibliogrfic o ar chi vos

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

por lista enlazada

una tabla en memoria

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

media nte lista enlazada

Rendimie nto del sistema de archivos

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

Impleme ntacin de directorios

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

Nue vas prestaciones

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

de ar chi vos estructurados

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

Casos de estudio de sistemas de archivos

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

HFS+ (HFS plus)

4 RELE VAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

Fragme ntacin en sistemas de archivos y Principio

5.1.1. ar chi vos

Desfragme ntacin y tcnicas archi vos actuales

la fragme ntacin en sistemas

de ar chi vos FAT se basa en la reubicacin de los bloques

Lneas de investigacin de archivos modernos

sobre tcnicas para evitar la fragme ntacin en sistemas

de ar chi vos NTFS

Bu er-ca che para la optimizacin

de tiem pos de acceso

5) Se inserta el nuevo bloque en la lista.

6 ELABOR ACIN DE UNA PROPUES TA DE SOLUCIN ALTERN ATIVA O

Ela boracin de una propuesta

de solucin alternati va o superadora

Localidad de archivos asociados

6 ELABOR ACIN DE UNA PROPUES TA DE SOLUCIN ALTERN ATIVA O

6 ELABOR ACIN DE UNA PROPUES TA DE SOLUCIN ALTERN ATIVA O

de localidad en ar chi vos asociados

tem poral de los accesos a archi vos por los pr ocesos

6 ELABOR ACIN DE UNA PROPUES TA DE SOLUCIN ALTERN ATIVA O

6 ELABOR ACIN DE UNA PROPUES TA DE SOLUCIN ALTERN ATIVA O

Mdulos que forman la solucin

6 ELABOR ACIN DE UNA PROPUES TA DE SOLUCIN ALTERN ATIVA O

Mdulo que impleme nta el algoritmo

de localidad en ar chi vos asociados

6 ELABOR ACIN DE UNA PROPUES TA DE SOLUCIN ALTERN ATIVA O

del mdulo de orquestacin

6 ELABOR ACIN DE UNA PROPUES TA DE SOLUCIN ALTERN ATIVA O

de log para m ntener la consistencia a