Tes Is Leguizamo

Tesis de grado de Ingeniera en informtica
Sistemas de Archivos.Tendencias y mejoras tecnolgicas
Universidad de Buenos Aires Facultad de Ingeniera Departamento de Computacin
Tutor: Lic. Arturo Servetto Tesista: Matas Leguizamo Padrn: 82375 E-mail: matias.leguizamo@gmail.com
NDICE
ndice
1. Objetivo 2. Dedicatoria 3. Introduccin 4. Relevamiento bibliogrco sobre sistemas de archivos
4.1. Asignacin de bloques a archivos 4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.2. 4.2.1. 4.2.2. 4.3. 4.4. Asignacin contigua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 6 7 8
8 8 9 9 10 11 11 12 12 12 13 13 13 13 14 15 15 15 16 16 18 21 24 26 26 26 28 28 28
Asignacin por lista enlazada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asignacin por lista enlazada utilizando una tabla en memoria Nodos-i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Administracin de espacio libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Administracin mediante mapa de bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Administracin mediante lista enlazada de unidades de almacenamiento libres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Seguridad 4.4.1. 4.4.2. 4.4.3.
Rendimiento del sistema de archivos Uso de cache Lectura adelantada de bloques
Reduccin del movimiento del brazo del disco . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5. 4.6.
Implementacin de directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nuevas prestaciones en sistemas de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1. 4.6.2. 4.6.3. Sistemas de archivos estructurados por registro . . . . . . . . . . . . . . . . . . . . . . . . . Sistemas de archivos por bitcora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistemas de archivos virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DOS (Disk Operating System) UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.
Casos de estudio de sistemas de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1. 4.7.2. 4.7.3. 4.7.4. 4.7.5. 4.7.6. 4.7.7. 4.7.8. 4.7.9. NTFS (New Technology File System)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
EXT-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXT-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXT-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HFS (Hierarquical File System): HFS+ (HFS plus) HPFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.10. ZFS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5. Relevamiento bibliogrco de mtodos y tendencias para optimizar el rendimiento de sistemas de archivo 30

5.1. Fragmentacin en sistemas de archivos y Principio de localidad 5.1.1. 5.1.2. 5.2. 5.2.1. 5.2.2. 5.2.3. 5.2.4. 5.2.5. 5.3. 5.3.1. 5.3.2. 5.3.3. 5.4. 5.4.1. 5.4.2. Principio de localidad . . . . . . . . . . . . . . . . . . . . 30 30 30 31 32 32 33 33 33 33 35 36 37 38 38 Fragmentacin de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Desfragmentacin y tcnicas para reducir la fragmentacin en sistemas de archivos actuales Sistemas de archivos Windows Sistema de archivos EXT-3
Sistemas de archivos archivos Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistema de archivos EXT-4, HFS+, ZFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistemas de archivos Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistemas de archivos NTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXT-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Buer-cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Poltica de reemplazo de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lneas de investigacin sobre tcnicas para evitar la fragmentacin en sistemas de archivos modernos 33
Buer-cache para la optimizacin de tiempos de acceso . . . . . . . . . . . . . . . . . . . . . . . . .
Tesis de grado de ingeniera en informtica.
NDICE
5.4.3. 5.4.4. 5.4.5. 5.4.6.
Sincronizacin para el reemplazo de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . Optimizacin en la performance del buer-cache por medio de algoritmos que utilizan informacin de la carga del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Optimizacin en la performance del buer-cache por medio de mejoras en la poltica de actualizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40 41 41 41
Colas mltiples de reemplazo para el segundo nivel de buer-cache . . . . . . . . . . . . . .
6. Elaboracin de una propuesta de solucin alternativa o superadora

6.1. Localidad de archivos asociados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1. 6.1.2. 6.1.3. 6.1.4. 6.2. 6.3. 6.4. Algoritmo de principio de localidad en archivos asociados Mtodo para evitar la fragmentacin en archivos asociados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heurstica para el algoritmo de principio de localidad en archivos asociados
44
44 44 46 46 46 46 48 48 49 49 49 49 50 51 52 52 52 52 53 53 54 54 55 56
Resultado de la reubicacin de archivos segn las relaciones . . . . . . . . . . . . . . . . . .
Persistencia temporal de los accesos a archivos por los procesos . . . . . . . . . . . . . . . . . . . . Depuracin de la tabla histrica de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mdulos que forman la solucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1. 6.4.2. 6.4.3. 6.4.4. 6.4.5. 6.4.6. 6.4.7. 6.4.8. 6.4.9. Mdulo que implementa el algoritmo del principio de localidad en archivos asociados . . . . Mdulo de merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mdulo de reubicacin de bloques Mdulo orquestador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Heurstica para la ejecucin del mdulo de orquestacin
Mecanismo de log para mantener la consistencia en caso de falla
Control de la concurrencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mdulo de rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mdulo de depuracin de la tabla histrica de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.10. Frecuencia de ejecucin del mdulo orquestador . . . . . . . . . . . . . . . . . . . . . . . . . 6.5. Modicaciones necesarias en Sistema de archivos NTFS para soportar esta tcnica 6.5.1. 6.5.2. 6.5.3. 6.5.4. 6.5.5. Cola compartida de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tabla histrica de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estructura utilizada para identicacin de inconsistencias tras una falla Estructura utilizada para por el proceso de rollback Modicaciones generales en los Sistemas de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7. Evaluacin Analtica y Experimental de la Propuesta

7.1. Evaluacin analtica 7.1.1. 7.1.2. 7.1.3. 7.1.4. 7.1.5. 7.1.6. 7.1.7. 7.2. 7.2.1. 7.2.2. 7.2.3. 7.2.4. 7.2.5. 7.2.6. 7.2.7. 7.2.8. 7.2.9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hiptesis sobre el tiempo de seek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hiptesis sobre el tiempo de latencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hiptesis sobre el tiempo de transferencia, . . . . . . . . . . . . . . . . . . . . . . . . . . . . Expresin general del tiempo de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grco del tiempo de seek en funcin de la distancia entre cilindros
57
57 57 57 58 58 58 59 60 60 60 63 64 64 66 66 67 68 69 70 71 71 72 89
Grco del tiempo de latencia en funcin de la distancia entre bloques . . . . . . . . . . . . Observaciones nales sobre el tiempo de acceso . . . . . . . . . . . . . . . . . . . . . . . . . Descripcin de la simulacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de arquitectura de la simulacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de secuencia de la simulacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cdigo fuente de mdulo FileSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cdigo fuente de mdulo TimesHelper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cdigo fuente de mdulo LocalityPrinciple Cdigo fuente de mdulo Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cdigo fuente de mdulo CartesianProductHelper
Evaluacin Experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cdigo fuente de mdulo Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.10. Cdigo fuente de mdulo Orchestrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.11. Cdigo fuente de mdulo RandomBlockSelector . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.12. Cdigo fuente de mdulo SecuentialBlockSelector . . . . . . . . . . . . . . . . . . . . . . . . 7.2.13. Anlisis comparativos de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.14. Resumen de los resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NDICE
8. Conclusin
8.1. 8.2. Anlisis de los resultados Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
90 91
9. ndice alfabtico 10.Referencias
92 94
NDICE
Imagine there's no Heaven It's easy if you try And no Hell below us Above us only sky
Imagine all the people Living for today Imagine there's no country It isn't hard to do
Nothing to kill or die for And no religion too Imagine all the people Living life in peace
You may say I'm a dreamer But I'm not the only one Maybe someday you will join us And the world will be as one
Imagine no posessions I wonder if you can No need for greed or hunger Or Brotherhood of Man
Imagine all the people Sharing all the world You may say that I'm a dreamer But I'm not the only one
And maybe someday you will join us And the world will be as one
You may say that I'm a dreamer But I'm not the only one Maybe someday you will join us And the world will be as one....
John Lennon, 1971
OBJETIVO
1. Objetivo
El objetivo del trabajo es 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 primer etapa est dedicada a un relevamiento bibliogrco y la confeccin de un informe sobre Sistemas de
Archivo.
La segunda etapa se centra en un relevamiento bibliogrco y la confeccin de un informe sobre tendencias tecnolgicas para optimizar el rendimiento de los sistemas de archivo. En
la tercer etapa se elaborar el planteo de una propuesta de solucin alternativa, superadora o comple-
mentaria para atacar los problemas detectados.
La cuarta etapa consiste en la evaluacin analtica y/o experimental de la propuesta.
DEDICATORIA
2. Dedicatoria
Vanesa (mi esposa) y a Tomy (mi hijo) que son las personas que me dan las Vane que ests a mi lado de manera incondicional desde que comenc la carrera y vos Tomy que me cambiaste la vida cuando naciste, gracias.
Este trabajo est dedicado a fuerzas necesarias para seguir adelante en esta carrera tan difcil y compleja. A vos A mi A
madre y a mi madrina por el sacricio y la ayuda que me dieron siempre, gracias.
Alberto por el sacricio que hizo durante 20 aos, gracias. cinco hermanos y a toda la gran familia que tengo, gracias. padre que desde algn lugar me est mirando y est orgulloso de su hijo, gracias
A mis
Muy especialmente a mi
por la familia que me diste y por todo. A todos los compaeros que pasaron meses sin dormir para terminar las entregas, gracias A
Favio, Dani y Jos.
Arturo por su tiempo y dedicacin. Universidad de Buenos Aires que me brind una educacin de excelencia de manera gratuita.
A la
INTRODUCCIN
3. Introduccin
La mayora de los sistemas de software requieren almacenar y recuperar informacin de dispositivos de almacenamiento 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 concurrente. La forma de almacenar la informacin es mediante archivos; stos son unidades lgicas de almacenamiento de informacin, y los sistemas de software o aplicaciones son los que deben saber interpretar los datos para transformarlos 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 almacenamiento. Existen dos operaciones que sobresalen del resto en cuanto a importancia, estas son la lectura y la escritura de bloques. Los archivos son administrados por el sistema operativo, y la parte del sistema operativo que trata la administracin de los archivos se conoce como
sistema de archivos, que es el tema de la tesis.
RELEVAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS
4. Relevamiento bibliogrco sobre sistemas de archivos

4.1. Asignacin de bloques a archivos
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 distintas 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 implementacin ya que los datos necesarios para la implementacin son el nmero del primer bloque y la cantidad de los mismos.
mnimo tiempo de seek posible (tiempo de posicionamiento de un bloque para ser leido) ya que los bloques
La otra virtud que tiene este mtodo es que la recuperacin del archivo completo se puede realizar con el son contiguos. Por lo tanto este mtodo tiene las ventajas de ser de fcil implementacin y adems tiene alto rendimiento; 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 fragmentacin (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 fragmentacin se vuelve problemtica porque en algn momento la unidad de almacenamiento 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 encontrar 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 variante se caracteriza por mantener los bloques de los archivos enlazados mediante referencias de manera que constituyan una lista. Se utilizan algunos bytes de cada bloque para apuntar al siguiente. Con este mtodo no se pierde espacio por fragmentacin (excepto por la fragmentacin 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 eciente. En la imagen 4.3 se ejemplica 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 ineciente 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 mtodo de la FAT, que tiene toda la tabla en memoria. El principal problema de este mtodo es que los i-nodes son de tamao jo, 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. bloques y no datos. En la imagen 4.5 se visualiza la estructura de un i-node. [1] Una manera de solucionar este problema es reservar el ltimo elemento de la lista de direccionamiento para direccionar un bloque que contiene direcciones de
10
4.2. Administracin de espacio libre

Cuando un archivo incrementa su tamao o se crea, es necesario obtener unidades de almacenamiento libres para insertar los datos. La administracin del espacio libre se puede realizar mediante un
mapa de bits o una lista
enlazada de unidades de almacenamiento libres. 4.2.1. Administracin mediante mapa de bits
Un mapa de bits es una estructura que asigna un bit de estado a cada unidad de almacenamiento (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 almacenamiento 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 vericar 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 secuencialmente toda la estructura hasta obtener los bloques que cubran el espacio libre requerido. La imagen 4.6 ejemplica este mtodo. [1]
11
4.2.2.
Administracin mediante lista enlazada de unidades de almacenamiento libres
Una lista enlazada es una estructura que tiene una referencia al siguiente nodo y al anterior. Cada uno de los nodos de la lista contiene informacin de una unidad de almacenamiento (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 ejemplica 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 reeren a permisos de lectura, escritura y ejecucin del archivo. Sobre un directorio estos permisos reeren bsicamente a las operaciones de lectura, escritura y ejecucin sobre los archivos que contiene. [2]
4.4. Rendimiento 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.
12
Como resultado de esta diferencia en el tiempo de acceso, muchos sistemas de archivos se han diseado con varias optimizaciones para mejorar el rendimiento.
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 rendimiento 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 almacenamiento 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 vericar si cierto bloque est en la cach de manera rpida, para esto se utiliza una tabla hash a la cual se accede mediante 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 almacenamiento, para la seleccin de dicho bloque se utilizan algoritmos como (menos recientemente utilizado),
LRU
FIFO (cola), etctera. [1]
4.4.2.
Lectura adelantada 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 vericacin 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 funcionamiento, para evitar esto se verica 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 movimiento del brazo del disco
Esta tcnica se basa en colocar los bloque que tengan probabilidad de utilizarse en secuencia uno a continuacin del otro, preferentemente 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. Implementacin 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 encontrar 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 ejemplica en la imagen 4.8.
13
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 encuentra la informacin del archivo como atributos, i-nodo, etc. Este mtodo se ejemplica en la imagen 4.9.
Otro tema importante para tratar es la implementacin de los nombres de los archivos: algunas implementaciones 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 implementarlo. Una posible implementacin 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 alternativa 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 encontrar 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 alternativa 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 eciente 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 verica 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. Nuevas 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.
cache de disco de una manera ms efectiva, garantizar la integridad (recuperacin de fallos) y proveer una interfaz virtual para trabajar con distintas implementaAlgunas de estas nuevas prestaciones son utilizar la ciones de sistemas de archivos.
14
4.6.1.
Sistemas de archivos estructurados por registro
El tipo de sistemas de archivos estructurado por registro naci como consecuencia del incremento de la velocidad de las CPU, del incremento en el tamao de las memorias RAM y del incremento en 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 buer en memoria, y periodicamente todas las pendientes se escriben en el disco (al nal del registro) como si fuera un solo segmento. Para que este mecanismo funcione cada segmento debe tener toda la informacin administrativa necesaria de las estructuras que contiene ya que puede contener
i-nodos (en el caso de unix), bloques de
directorios, bloques de archivos, etc.[1]

Este mtodo se ejemplica 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. Periodicamente se recorre el cclica comenzando por el que ya no son utilizados.
registro de manera primer segmento y analizando la informacin que contiene para liberar los bloques
4.6.2.
Sistemas de archivos por bitcora
La idea de este sistema de archivos es mantener 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 signica 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 o ninguna. [1]
transacciones, de
esta manera el sistema de archivos agrupa operaciones a realizar y sabe que deben ejecutarse sin problema todas
4.6.3.
Sistemas de archivos virtuales sistema de archivos virtual (VFS) es integrar
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 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,
15
read, write, lseek, etctera. Por lo tanto, el interfaz llamada El
VFS tiene una interfaz superior para los procesos de usuarios y es la
POSIX.
VFS tambin tiene una interfaz inferior para los sistemas de archivos concretos, esta interfaz consiste de VFS puede hacer a cada sistema de archivos para realizar su trabajo. Por lo tanto para que un sistema de archivos trabaje con el VFS basta con que suministre las llamadas a las funciones que realiza el VFS.
llamadas a funciones que el En la imagen 4.11 se ejemplica 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 ejemplicarn 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 almacenamiento 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
16
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 especca 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 Modicacin 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 encuentra 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 cada direccin de disco.
FAT-12, FAT-16 o FAT-32, dependiendo de la cantidad de bits que tenga
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 aproximadamente 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 incrementa 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 almacenamiento 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]
17
4.7.2.
NTFS (New Technology File System)
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 oset desde el inicio de la particin mediante un nmero de 64 bits. La estructura principal es la llamada
MFT(Tabla maestra de archivos), 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 encuentran 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 (encabezado 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 sucientemente corto como para caber en el registro se deja all, en caso contrario se almacena en algn lugar de la unidad de almacenamiento y se almacena su ubicacin en el valor del par atributo-valor en cuestin.
18
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 dene 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 ja. El campo nombre de archivo contiene el El campo
nombre del archivo en unicode y es de longitud variable.
descriptor de seguridad slo se utiliza en NT 4.0 ya que en los siguientes sistemas operativos
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 El campo
ID de objeto se utiliza para acceder a los archivos. punto de reanlisis indica en nombre del procedimiento que se utiliza para montar sistemas de
archivos de manera explcita y para los vnculos simblicos. Los campos de Los campos
volumen se utilizan para identicar el volumen.
raz de ndice, asignacin de ndice y mapa de bits se relacionan con la manera en que
se implementan los directorios, los pequeos son listas de archivos, y los grandes son rboles B+. El campo ujo de El campo
utilera con registro es usado por el sistema de archivos de cifrado.
datos representa los datos del archivo, en el caso que los datos sean pocos se ubican en este
atributo (archivo inmediato), en caso contrario representa las direcciones de los clusters del archivo. [1]
19
Asignacin de los clusters para el almacenamiento: Por cuestiones de eciencia los clusters de un archivo se almacenan de manera contigua siempre que sea posible. Cada conjunto de clusters contiguos de un archivo se describe mediante un registro. Esto ser analizado en detalle en la seccin de
relevamiento bibliogrco y tendencias tecnolgicas.
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
comprimida, en el caso de que no se puedan comprimir los datos se guardan sin comprimir. Lo mismo se hace para las siguientes secuencias de clusters, siempre tomando de a 16 salvo en la
comprimirlos se guardan de manera 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 faltantes 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 nal (comprimido).
20
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) correspondiente, si la direccin inicial es 0 indica que es parte nal de 16 clusters comprimidos, 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 buer del sistema, este buer 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 mediante llamadas a la API de NtfsControlFile, esta funcin es la llamada FSCTL_QUERY_USN_JOURNAL. [1]
4.7.3.
UNIX
En Unix, el sistema de archivos es uno de los componentes del kernel. Los procesos 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 especcos de cada uno. los dispositivos. Esto se puede observar en la imagen 4.16. Cabe mencionar que la unidad mnima de almacenamiento en UNIX se denomina bloque y no un cluster como en NTFS. [2] En el
caso de que los dispositivos son orientados a bloques, existe un nivel de buering entre el sistema de archivos y
I-Nodos:
21
La estructura principal para la administracin de los archivos es el y contiene la siguiente informacin:
i-nodo, esta estructura es de tamao jo
Identicacin del creador del archivo. Tipo de archivo, esto es por ejemplo, normal, directorio, etc. 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 independiente al dueo del archivo, a su grupo y al resto de los usuarios. Fecha de la ltima modicacin del archivo, ltimo acceso al mismo, ltima fecha de modicacin del i-nodo, 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 distintos nombres, estas referencias se denominan Tamao del archivo. Tabla de asignacin de Este campo suele utilizarse adems para
links.
DataBlocks, 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
DataBlock. Dado que los i-nodos son de tamao jo y que la cantidad de bloques del archivo correspondiente 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 mientras que las siguientes referencian a bloques que contienen direcciones de bloques. Los niveles de indireccin pueden ser varios. La imagen 4.17 representa un esquema de indireccin de tres niveles. [2]
22
Tablas del Kernel: Los i-nodos se almacenan en los mismos dispositivos de almacenamiento 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 del i-nodo correspondiente, adems de la siguiente informacin: 1. Referencia al sistema de archivos en el que se encuentra 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 encuentra en espera para acceder al archivo asociado al i-nodo), indica adems si el i-nodo se modic en memoria pero no se persisti en el medio de almacenamiento, 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 correspondiente de la tabla de i-nodos, adems y mantiene informacin adicional como la posicin de lectura o escritura dentro del archivo (oset), 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 el proceso abre dos veces el mismo archivo recibir dos
le descriptor con el que el proceso acceder al archivo. Si un 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 mediante la cual el kernel mantiene dos osets diferentes al mismo archivo para el mismo proceso. Existen calls que permite evitar este comportamiento. [2] Directorios: Un directorio es un archivo cuyo contenido es una secuencia de registros de longitud variable que contienen la longitud del registro, un nmero de i-nodo, la longitud y la secuencia de caracteres que representan 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 mediante las system calls correspondientes, esto permite garantizar la integridad del sistema de archivos. Los campos de permisos de los directorios tienen un signicado 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]
23
Buering: Como se mencion anteriormente, los drivers de los dispositivos orientados a bloques se comunican con el sistema de archivos mediante una tcnica de buering. La cantidad de buer que el kernel administra es un parmetro del sistema operativo, y el control de los mismos se implementa mediante colas de dispersin doblemente 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 buer libre. 7. Puntero al anterior buer libre. 8. Estado, este valor puede ser, bloqueado, datos vlidos, se debe escribir antes de reasignarlo, se est leyendo o escribiendo actualmente, un proceso est esperando que se libere el buer. 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 ext, este tena varios problemas en el ext-2.
Este sistema de archivos se cre para reemplazar a su predecesor llamado rendimiento. La imagen 4.19 nuestra una particin con
24
El bloque 0 contiene informacin para el inicio de la computadora, luego de este la particin se divide en conjuntos de bloques. El
sper bloque 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 grupo 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 representan los bloques libres y los utilizados. Estos mapas son de tamao jo, por
lo tanto la cantidad de bloques que pueden mapear est limitada. Por ltimo estn los
i-nodos y luego los bloques de datos, aqu se almacenan todos los datos de los archivos
y directorios, puede ocurrir que si un archivo es lo sucientemente 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 extremadamente 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]
25
4.7.5.
EXT-3 ext-2, y se caracteriza por tener una implementacin de transacciones.
Este sistema de archivos es el sucesor de
Cada modicacin en el sistema de archivos se graba en un archivo secuencial, de esta manera si se produce una falla en el sistema, al iniciar nuevamente 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 turas de datos principales,
dispositivo de bloque transaccional (JBD).El JBD proporciona tres estrucel registro diario, el manejador de operaciones atmicas y la transaccin. 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 notica 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 verica que se aplicaron los cambios que ellos representan, de esta manera se evita tener operaciones en el archivo de transacciones que ya fueron aplicadas. [1]
4.7.6.
EXT-4 ext-3 y tiene varias mejoras con respecto a ste que se enumeran a
Este sistema de archivos es el sucesor de continuacin.
1. Es capaz de trabajar con volmenes de hasta 1EByte y el tamao mximo de archivos es 16TByte. 2. El concepto de bloques utilizado en unix se reemplaza por
extents, estos son grupos de bloques contiguos
que permiten mejorar el uso de archivos de gran tamao y se reduce la fragmentacin. 3. Se implement una nueva llamada al sistema
(preallocate()) que se agreg al kernel de Linux, esta op-
eracin realiza la reservacin de espacio para un archivo siendo muy probable que sea contiguo. 4. Se implement una tcnica que mejora el rendimiento llamada
Allocate-on-ush, esta consiste en retrasar
la reserva de bloques en memoria hasta que la informacin est a punto de ser persistida en la unidad de almacenamiento. Esta tcnica mejora el rendimiento y reduce la fragmentacin 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): Data fork y otra llamada resource fork. La seccin data fork contiene los datos creados
Este sistema de archivos no maneja los archivos como streams solamente, sino que estn formados por dos partes, una seccin llamada 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 implementada 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 nder que se encarga de consultar el rbol B* para obtener los resultados. En la imagen 4.21 se muestra la estructura de un volumen de HFS.
26
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 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 consiste en un
le thead record y un le record, mientras que cada directorio directory thead record y un directory record.
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, modicacin 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 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, modicacin y ltimo backup), almacena dos campos de 16 bytes para uso del nder. 5. El archivo de desbordamiento 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 direccionamiento 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 modica un archivo o directorio se accede al catalog le, dado que ms de un proceso no puede modicar 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]
27
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 incrementar si la particin crece, este nuevo archivo es llamado
allocation le. 32 bits, con esto se termina la limitacin
2. El direccionamiento a los bloques se realiza mediante un nmero de 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 implement un nuevo archivo (B*) llamado
atributes le para direccionar atributos, este archivo es
utilizado por el 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 implement 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 Unicode. [2] [5]
4.7.9.
HPFS
Este sistema de archivos fue creado especicamente 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 eciente para organizar los directorios, de esta manera, se utiliza menos espacio en el almacenamiento 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 (anteriormente separados) como sistema de archivos y administrador de volmenes, sencilla administracin del espacio de almacenamiento. Algunas de las caractersticas se mencionan a continuacin: 1. Los punteros a bloques contienen un checksum de 255 bits sobre el bloque apuntado 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 modicados 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 incrementa el trabajo de procesador.
28
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 un solo dispositivo, ZFS utiliza espacios de almacenamiento virtuales. Estos se construyen a partir de uno o ms dispositivos virtuales, de esta manera el sistema de archivos puede estar montado en un dispositivo que tenga menor capacidad de almacenamiento del que se necesita y utilizar otros para compensar la falta de espacio. [8]
29
RELEVAMIENTO BIBLIOGRFICO DE MTODOS Y TENDENCIAS PARA OPTIMIZAR EL
RENDIMIENTO DE SISTEMAS DE ARCHIVO
5. Relevamiento bibliogrco de mtodos y tendencias para optimizar el rendimiento de sistemas de archivo

En esta etapa se analizarn las lneas de investigacin sobre las siguientes problemticas en los sistemas de
prdida de performance en el tiempo de accedo debido al no cumplimiento del principio de localidad, y aplicacin de buer-cache para la optimizacin de tiempos de acceso.
archivo,
5.1. Fragmentacin en sistemas de archivos y Principio de localidad

5.1.1. Fragmentacin de archivos
Al crear, copiar o mover un archivo en la unidad de almacenamiento, el sistema operativo busca bloques de espacio libre en disco contiguo, donde puede escribir el archivo. Cuando el sistema ope rativo no puede encontrar suciente espacio contiguo, busca el espacio libre no contiguo necesario en la unidad de almacenamiento. Como resultado, los bloques del archivo pueden quedar dispersos en lugar de un rea contigua de la unidad de almacenamiento. Cuando los bloques de un archivo quedan dispersos se conoce como un archivo fragmentado.
n bloques que lo forman para obtener toda su informacin, (tiempo de seek), si el archivo est fragmentado este tiempo ser mayor que el tiempo de accesso de un archivo no fragmentado.
Acceder a un archivo implica que se localicen los para realizar el acceso a un bloque primero debe ser ubicado debajo de la unidad de lectura [16] En la imagen 5.1 se visualiza la distribucin de los bloques que forman un archivo.
5.1.2.
Principio de localidad archivo A formado por n bloques, es contiempo de seek sea el mnimo posible. La fragmentacin en los
El principio de localidad plantea el siguiente escenario, dado un veniente tenerlos ubicados de manera que el
archivos genera que los bloques de los mismos no cumplan con el principio de localidad.
30
tiempo t1 se crea el archivo A formado por 10 bloques ubicados de manera contigua. En el tiempo t2 se borran 5 bloques del archivo A.
Para representar esta problemtica se plantea el siguiente escenario, en el En la imagen 5.2 se plantea cmo queda formado en archivo A en el tiempo
t2 .
En el
tiempo t3 se crea el archivo B formado por 4 bloques, estos se insertan en los bloques libres 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 .
se pierde el principio de localidad con el transcurso del tiempo, a causa de este motivo se ve incrementado el tiempo de lectura del archivo A. El escencario planteado es
En la situacin planteada se deduce de qu manera extremadamente bsico, pero en un sistema de archivos real el efecto causado por la maniplacin de sus archivos es que el
principio de localidad deje de cumplirse para muchos de estos y la performance se vea decrementada,
estudios como los que se plantean en [13] indican este fenmeno.
5.2. Desfragmentacin y tcnicas para reducir la fragmentacin en sistemas de archivos actuales

La desfragmentacin 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 almacenamiento, el n
31
de esto es que se
cumpla con el principio de localidad.
A continuacin se analizan los procesos de desfragmentacin en varios de los sistemas de archivos actuales.
5.2.1.
Sistemas de archivos Windows
Familia de sistemas de archivos FAT sistemas de archivos FAT se basa en la reubicacin de los bloques de
El proceso de desfragmentacin en los los archivos fragmentados. Los pasos son los siguientes:[10]
1. Anlisis del espacio libre en la unidad de almacenamiento. En el proceso de desfragmentacin se realizan copias temporales (una por archivo fragmentado), por este motivo es necesario disponer de espacio en la unidad de almacenamiento para realizar las copias necesarias. Estos nuevos archivos tienen los bloques ubicados de manera que cumplan el principio de localidad lo ms que sea posible. 2. Deteccin de los archivos fragmentados. Esta etapa del proceso se encarga de decidir si se desfragmenta o no.
buscar todos los archivos fragmentados, para este n se calcula
su nivel de fragmentacin (cantidad de bloques no contiguos) y se compara con un valor determinado para En este anlisis se evitan los archivos que son utilizados por el sistema operativo para su conguracin y correcto funcionamiento, archivos defectuosos. 3. Copia de los bloques de los archivos encontrados 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 almacenamiento con el espacio necesario para ello. 4. Comparacin de los archivos originales con los nuevos. Esta etapa se encarga de corroborar 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 de las copias generadas. 6. Borrado de los bloques originales. En esta etapa se eliminan los archivos originales, esto se debe a que ya no son utilizados porque fueron reemplazados por los que se generaron en el paso 3.
desfragmentados son modicadas por las referencias
Familia de sistemas de archivos NTFS

En el caso de los
se dan en los pasos 2 y 5. Esto se debe a que
sistemas de archivo NTFS, los pasos son los mismos que los de la familia FAT, las diferencias NTFS no utiliza una tabla FAT, sino que utiliza una tabla llamada
MFT. En esta tabla se almacenan las referencias a los clusters que forman los archivos, por lo tanto es de aqu
de donde se toman las referencias para el paso 2, y es donde se modican las referencias de los clusters de los archivos originales. Los sistemas operativos windows se basan en que el usuario decida ejecutar el proceso de desfragmentacin. Desde la versin de Windows Vista existe un proceso que se ejecuta background y realiza tareas de desfragmentacin.[10]
5.2.2.
Sistemas de archivos archivos Unix
agrupacin por cilindros . Esta tcnica se basa en dividir el espacio fsico de la unidad de almacenamiento en cilindros.
Los sistemas de archivos Unix, para reducir la fragmentacin, implementan una tcnica llamada 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 fragmentacin ya que la separacin de
32
los bloques est limitada a los cilindros o a cilindros cercanos.[12] Est tcnica es utilizada en sistemas de archivos como Existen herramientas como ejecutadas por el usuario. La desfragmentacin 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.
EXT-2, EXT-3 y EXT-4. e2defrag (se utiliza en EXT-2) que realizan la desfragmentacin y que deben ser
5.2.3.
Sistema de archivos EXT-3 Shake y Defrag. Shake trabaja
Para este sistema de archivos existen herramientas para la desfragmentacin como
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 almacenamiento. 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 almacenamiento 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 fragmentacin es la llamada pero al
copy-on-write ,
este mtodo se basa en asignar los mismo bloques para los distintos archivos al momento de reservar espacio libre,
momento de persistir la informacin se asignan bloques nuevos para el archivo en cuestin.[11] Sistema de archivos EXT-4, HFS+, ZFS delayed allocation, este consiste en retrasar la reserva
Esto mejora el rendimiento y reduce la
5.2.4.
Estos sistemas de archivos utilizan el mtodo llamado
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. fragmentacin al mejorar las decisiones de reserva de bloques basada en el tamao real del archivo.[14]
5.2.5.
Ventajas y desventajas desventaja ya que muchos usuarios no conocen la existencia de estas
Varios de los sistemas operativos no ejecutan el proceso de desfragmentacin de manera automtica, requieren que el usuario lo indique. Esto es una gran herramientas. Algunos sistemas de archivo implementan diferentes tcnicas para disminuir la fragmentacin, otros no, lo cual es una
desventaja.
5.3. Lneas de investigacin sobre tcnicas para evitar la fragmentacin en sistemas de archivos modernos
En esta seccin se tratarn en detalle tcnicas utilizadas para evitar la fragmentacin en sistemas de archivos Unix y NTFS.
5.3.1.
Sistemas de archivos Unix
Como se mencion en secciones anteriores, cuando se graban los bloques de un archivo, estos pueden ubicarse en secciones no contiguas de la unidad de almacenamiento; esto provoca que al momento de leer dichos bloques, la unidad de lectura necesite realizar movimientos por varias pistas de la unidad de almacenamiento. 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 de pistas de la unidad de almacenamiento en un cilindro.[12] Al momento de realizar la persistencia de los bloques del archivo se ubican segn la
agrupacin por cilindros (imagen 5.4); esta tcnica se basa en dividir la unidad de almacenamiento en cilindros, es decir, agrupar un nmero 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 almacenamiento se reduce de manera considerable ya que el tiempo de acceso est totalmente relacionado con el tiempo de posicionamiento de la unidad de lectura, por lo tanto, al disminuir dicho tiempo
reducimos el tiempo de acceso.
33
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 2. Si no se encuentra ningn bloque disponible en el del
mismo cilindro.
mismo cilindro, se asigna un bloque de otro cilindro
mismo grupo de cilindros. est totalmente lleno, se utiliza una funcin de hash para obtener el nmero de se repiten los pasos uno y dos.
3. Si el grupo de cilindros
otro grupo de cilindors en el que 4. Finalmente,
si el paso tres falla, se busca en todos los grupos de cilindros.
La heurstia presentada es la utilizada para la asignacin de bloques a los archivos y directorios. Cada grupo de cilindros contiene informacin acerca de los bloques que almacena: 1. Un
Bitmap que indica los bloques libres. i-nodos que contiene. superbloque.
2. La lista de
3. Una copia del
En el trabajo [12] se realizaron pruebas relacionadas con el rendimiento 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 trabaja sin respetar el principio de localidad.
34
5.3.2.
Sistemas de archivos NTFS principio de localidad los clusters de un archivo se almacenan de manera contigua siempre que
Basado en el
sea posible. Cada conjunto de clusters contiguos de un archivo se describe mediante 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 represente ambos conjuntos. Cada registro comienza con un encabezado que proporciona el desplazamiento de los datos del primer conjunto dentro del registro, luego el desplazamiento 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 representa un registro de la MFT para tres conjuntos de clusters consecutivos. En el caso en que el archivo sea tan grande o tan fragmentado y la 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 suciente 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
35
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. ma lineal, se utiliza un rbol B+ para que sean bsquedas ptimas. En vez de listar todos los archivos en for-
Para realizar la bsqueda del archivo C:\foo\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 encontrar 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 reere 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 fragmentacin de los archivos, estas son
extents, preallocate y allocate-on-ush.[15] Extents: Ext3 utiliza un alocador de bloques que decide cules de los que se encuentran libres van a ser
utilizados para escribir los datos, para llevar a cabo esta accin se realiza una llamada por bloque, lo cual es ineciente por ser demasiadas llamadas las que se realizan. Para mejorar este aspecto los bloques (en lo posible de manera contigua) necesarios, este conjunto de bloques es denomina
Ext4 incorpora un alocador multi-bloques que en una sola llamada aloca todos extends.
36
Las estructuras utilizadas phara el funcionamiento de esta tcnica son las siguientes:
/* * This is the extent on-disk structure. * It's used at the bottom of the tree. */ struct ext4_extent { __le32 ee_block; /* rst logical block extent covers */ __le16 ee_len; /* number of blocks covered by extent */ __le16 ee_start_hi; /* high 16 bits of physical block */ __le32 ee_start_lo; /* low 32 bits of physical block */ };h /* * This is index on-disk structure. * It's used at all the levels except the bottom. */ struct ext4_extent_idx { __le32 ei_block; /* index covers logical blocks from 'block' */ __le32 ei_leaf_lo; /* pointer to the physical block of the next, level. leaf or next index could be there */ __le16 ei_leaf_hi; /* high 16 bits of physical block */ __u16 ei_unused; }; Estas dos estructuras representan las hojas que se utiliza para acceder al extend.
(ext4_extent) y los nodos internos (ext4_extent_idx) del rbol
Preallocate: Para incrementar la probabilidad de que los bloques asignados a un Extend sean contiguos
es necesarios reservarlos lo ms rpido posible, para esto se implement una nueva SystemCall (preallocate) al kernel de Linux, esta operacin realiza la reserva de bloques cuando es invocada.
Allocate-on-ush: Una tcnica que tiene la misma nalidad que Preallocate (trabajan de manera diferente y tienen el mismo propsito) es Allocate-on-ush, esta consiste en retrasar la reserva de bloques hasta
que la informacin est a punto de ser persistida en la unidad de almacenamiento. Esta tcnica mejora el rendimiento y reduce la fragmentacin al mejorar las decisiones de reserva de memoria basada en el tamao del archivo.
5.4. Buer-cache para la optimizacin de tiempos de acceso

Como se mencion anteriormente, cuando se accede a un bloque tenemos tres tiempos para analizar: 1. El tiempo que tardan los cabezales en posicionarse en el cilindro donde se encuentra el sector a leer o escribir
(tiempo de seek).
2. El tiempo de rotacin para que el sector a leer o escribir se encuentre con el cabezal(tiempo 3. El tiempo de lectura o escritura
de latencia).
(tiempo de transferencia).
Estos tiempos no son menores, por lo tanto se pueden aplicar tcnicas para reducirlos, una de estas es la utilizacin de
buer-cache.
37
5.4.1.
El
Buer-cache
buer-cache es una cache de bloques y su objetivo es minimizar accesos a la unidad de almecenamiento,
el por qu de este objetivo es que el acceso a la unidad de almacenamiento para acceder a bloques es de varios rdenes mayor que el tiempo de acceso a la memoria principal. Una manera de implementar esta tcnica es mediante listas enlazadas en memoria donde cada dispositivo de almacenamiento tiene asociada una o ms listas de bloques, las mismas se acceden mediante una hash que se calcula con la direccin del dispositivo. La imagen 5.7 muestra una ejemplicacin de la implementacin del buer-cache mediante 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 implementar algn tipo de poltica de reemplazo.
38
Una posibilidad (y la ms utilizada) es la tcnica denominada tiene mayor tiempo sin accederse.
LRU, esta consiste en reemplazar el elemento que
La imagen 5.8 representa el proceso de reemplazo de un bloque segn la poltica LRU.
Cada uno de los bloques cargados en las listas tienen un
status que reeja su estado. A modo de optimizacin, status para saber si debe ser
cada bloque se mantiene en memoria sin persistir su informacin en la unidad de almacemamiento hasta que se reemplace por otro, por lo tanto en el momento en que se reemplace se analizar su persistido en la unidad de almacenamiento o no. A continuacin se presenta una heurstica que representa este mecanismo.
1) Se intenta insertar un nuevo bloque en la lista. 2) En caso de que haya espacio se inserta. 3) En caso de no poder insertarlo se busca el bloque a reemplazar. 4) Si el bloque que se va a quitar de la lista est modicado se persiste en la unidad de almacenamiento.
39
5) Se inserta el nuevo bloque en la lista.
5.4.3.
Sincronizacin para el reemplazo de bloques sincronizacin al momento de querer modicar o reemplazar uno de los bloques status del bloque, si el status sincronizar el acceso a los nodos
Esta tcnica tiene problemas de
que est en alguna de las listas. Un mtodo para evitar este problema es analizar el hasta que quede libre. Este es el mecanismo ms tradicional y ms simple para de la lista. La imagen 5.9 representa el proceso de sincronizacin de bloques.
indica que el bloque est siendo utilizado por otro proceso, el proceso que quiere tomar el bloque queda en espera
A continuacin se presenta una heurstica para este proceso:
1) Se accede a un bloque de la lista.
40
2) Si est libre es tomado, caso contrario se ejecuta el paso 4. 3) Se modica 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 buer-cache por medio de algoritmos que utilizan informacin de la carga del sistema buer cache que consiste en lo siguiente, se
En el trabajo [17] se analiz una optimizacin para el mtodo de
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 durante la ejecucin de los algoritmos. El rendimiento de las operaciones en el buer-cache se mejora mediante el uso de estos algoritmos que permiten escribir el contenido del buer-cach en la unidad de almacenamiento en funcin de la carga del sistema y la actividad de escritura. La conclusin del trabajo 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 almacenamiento en funcin de la tasa de operaciones de es-
Se demostr que los algoritmos propuestos permiten un mejor rendimiento que un algoritmo que no utiliza informacin sobre la carga del sistema.
critura y el nmero de procesos activos en el sistema.
5.4.5.
Optimizacin en la performance del buer-cache por medio de mejoras en la poltica de actualizacin manera retardada o peridicamente, en el trabajo [18] se analiz una posible optimizacin
Cuando los bloques son modicados deben ser escritos en la unidad de almacenamiento, esto se realiza inmediatamente, de para el mtodo de buer 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 almacenamiento cuando cumple cierto tiempo de estar en estado modicado. En la experimentacin se ejecutaron dos procesos corriendo al mismo tiempo:
Un generador de escrituras, congurado para realizar escrituras cada 30 segundos. Un generador de lecturas, en el mismo 10.000 bloques son elegidos al azar.
Adems se utilizaron dos sistemas de hardware diferentes, uno ms rpido que el otro. En el trabajo 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 tiempos de respuesta mejoran de manera signicativa. 5.4.6. Colas mltiples de reemplazo para el segundo nivel de buer-cache
En el trabajo [19] se plante un nuevo nivel de buer cache con un algoritmo que utiliza colas mltiples para alocar los bloques. Originalmente el plateo est destinado a servidores distribuidos, pero esta idea puede aplicarse a una computadora local que trabaja con los dos niveles de buer cache. La imagen 5.10 representa la estructura necesaria mediante un diagrama de bloques.
41
El algoritmo utilizado mantiene los bloques en el segundo nivel de buer 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 corresponda segn su frecuencia de acceso. En un miss, el bloque es ubicado en la cola correspondiente a la menor frecuencia de accesos posible. A continuacin se presenta el pseudocdigo del algoritmo MQ:
42
La conclusin del trabajo es que el ratio de hits se incrementa en un 10 % respecto a la no utilizacin de la tcnica plateada, por lo tanto los tiempo de acceso a bloques decrecen.
43
ELABORACIN DE UNA PROPUESTA DE SOLUCIN ALTERNATIVA O SUPERADORA
6. Elaboracin de una propuesta de solucin alternativa 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 procesos en background para incrementar la performance, estas dos tcnicas se van a complementar para formar la propuesta nal.
Adems se deben realizar modicaciones en las estructuras de los sistemas de archivos para darle soporte a esta nueva tcnica, en el actual trabajo se plantearn las nuevas estructuras y modicaciones en general, quedando para trabajos a futuros realizar las implementaciones de las mismas.
6.1. Localidad de archivos asociados

Con frecuencia sucede que un proceso accede a un conjunto de archivos para leerlos o manipularlos. Este 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 cercanamente posible dentro de la unidad de almacenamiento
(principio de localidad), el caso ideal es que estn ubicados adyacentemente.
2. Favorece a la performance que los bloques que forman un archivo estn ubicados lo ms cercanamente posible dentro de la unidad de almacenamiento adyacentemente.
(archivos no fragmentados), el caso ideal es que estn ubicados
6.1.1.
Algoritmo de principio de localidad en archivos 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
(archivo 1, archivo 2, cantidad 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 identican mediante 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 presenta una ejemplicacin de este proceso. Universo de archivos: A, B, C, D, E, F, G, H, I
44
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 representa el resultado nal luego de reubicar los archivos segn la tabla de relaciones. Este proceso debe realizar la modicacin de todas las referencias
fsicas (por las nuevas ubicaciones) de los
bloques de los archivos para mantener la integridad del sistemas de archivos.
45
6.1.2.
Heurstica para el algoritmo de principio de localidad en archivos asociados
1) Para cada proceso repetir los siguiente pasos. 2) Obtener todos los archivos referenciados. 3) Armar todas las relaciones posibles para la salida del paso 2. 4) Armar las ternas
(archivo 1, archivo 2, cantidad de repeticiones) para la salida del paso 3.
5) Ordenar la salida del paso 4 por cantidad de ocurrencias y en caso de empate por id de archivo. 6) Fusionar la salida del paso 5 con las ternas 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.
Mtodo para evitar la fragmentacin en archivos asociados
Los bloques de un archivo (con el pasar del tiempo) dejan de estar ubicados de manera contigua en la unidad de almacenamiento. Como ya se mencion, este fenmeno provoca la fragmentacin 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 archivos segn las relaciones
El resultado de la reubicacin de los archivos relacionados nos garantiza tener
disminuir la fragmentacin, as como ubicados de manera adyacente los que estn relacionados. La disminucin de la fragmentacin 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 posicionamiento sobre los archivos que utilizan los procesos por estar ubicados de manera adyacente.
relaciones de archivos no debe eliminarse nunca, lo que se debe hacer es depurarla depuracin de la tabla histrica de relaciones.
La tabla histrica de ya que con el tiempo se eliminan algunos archivos, esto se analizar en la siguiente seccin llamada
6.2. Persistencia temporal de los accesos a archivos por los procesos

algoritmo de principio de localidad en archivos asociados (6.1.1), para esto se plantea la siguiente estructura:
Las relaciones entre archivos deben ser persistidas para poder realizar el Una
minado(imagen 6.3),
cola compartida, la cual tendr en cada nodo una lista de archivos accedidos por un proceso detersta ser manipulada por el sistema de archivos.
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).
46
Esta estructura ser analizada por un proceso (analizado en secciones posteriores) que se encargar de leer y modicar todas las estructuras necesarias para llevar a cabo el algoritmo 6.1.1.
La imagen 6.4 representa la actualizacin de la cola compartida de archivos accedidos.
47
6.3. Depuracin de la tabla histrica de relaciones

Con el paso del tiempo los archivos tienden a ser eliminados de la unidad de almacenamiento, por lo tanto la tabla global de relaciones deja de tener coherencia con respecto a lo archivos almacenados. La tabla de relaciones crecer indefectiblemente con el paso del tiempo, por lo tanto su lectura ser cada 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 debe
representar archivos que existan en la unidad de almacenamiento.

La solucin para este problema es
depurar la tabla global de relaciones para eliminar aquellas que es-
tn formadas por al menos un archivo que no exista. La imagen 6.5 representa el proceso de depuracin.
Como se observa en la imagen, el tamao de la tabla de relaciones baja considerablemente al ser depurada.
6.4. Mdulos que forman la solucin

Para la solucin denitiva se plantea la utilizacin de una serie de mdulos que sern orquestados por otro, a continuacin se detalla cada uno de los ellos. 1. 2.
Mdulo que implementa el algoritmo del principio de localidad en archivos asociados (6.1.1). Mdulo de merge.
48
3. 4. 5. 6.
Mdulo de reubicacin de bloques. Mdulo orquestador. Mdulo de depuracin de la tabla histrica de relaciones. Mdulo de rollback.
6.4.1.
Mdulo que implementa el algoritmo del principio de localidad en archivos 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 posteriormente 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 bloques
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 modican 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 presenta en la imagen 6.6.
49
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.
50
6.4.6.
Mecanismo de log para mantener la consistencia en caso de falla
En ocasiones puede ocurrir que durante la ejecucin del mdulo orquestador el sistema falle (corte de luz por ejemplo), esto puede generar que el sistema de archivos deje de mantener la consistencia. Para solucionar este problema se plantea lo siguiente, crear una estructura de log que sea analizada por 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 presenta 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 conjunta. Cuando nalice completamente la ejecucin de reubicacin de bloques y modicacin de referencias se setea el campo de resultados.
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
START y no END implica que hubo un error durante la ejecucin del mdulo de reubicacin para el nmero de registro en cuestin, por lo tanto lo que se hace es deshacer los cambios realizados, que en el peor de los casos
Cuando arranca el sistema de archivos se analiza esta estructura, en caso que exista el campo el campo es marcar como libre a todos los nuevos bloques que fueron copiados. Para llevar a cabo esta accin es necesario tener persistidos los datos correspondientes 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 mantener consistencia luego de una falla en el sistema.
En esta estructura se guarda la referencia a los nuevos bloques creados durante 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 archivos 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
51
cabo por el mdulo de rollback.
6.4.7.
Control de la concurrencia
Durante la ejecucin del mdulo orquestador pueden ocurrir los siguientes escenarios que son potencialmente 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 rollback no aplicados. Al iniciar
Este mdulo es el encargado de llevar a cabo la eliminacin de los ltimos cambios rollback. Como todos los mdulos, es ejecutado por el
el sistema realizar el anlisis de la estructura que gura en la imagen 6.8, y en caso de ser necesario realiza el
mdulo orquestador.
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. Frecuencia de ejecucin del mdulo orquestador
6.4.10.
El mdulo orquestador tiene tres funciones que son las siguientes: 1. Ejecutar el
ejecutar el mdulo orquestador indicndole que realice la accin de la consistencia. 2. Ejecutar el
mdulo de rollback, esta ejecucin se efecta cuando inicia el sistema de archivos, es decir, este rollback en cambios que no mantienen mdulo del principio de localidad en archivos asociados, esta ejecucin se efecta en
intervalos de un cierto tiempo que es un parmetro de conguracin del sistema. 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
el mismo intervalo que el intercalada con este.
mdulo de depuracin de la tabla histrica de relaciones, esta ejecucin se efecta en mdulo del principio de localidad en archivos asociados, pero de manera
52
6.5. Modicaciones necesarias en Sistema de archivos NTFS para soportar esta tcnica
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 archivos 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.
53
6.5.2.
Tabla histrica de relaciones
Para esta estructura se plantea utilizar un archivo formado por registros de longitud ja, cada registro est formado por los siguientes campos:
Identicador1: Identicador del primer archivo de la relacin. Identicador2: Identicador del segundo archivo de la relacin. Cantidad de repeticiones: Cantidad de repeticiones de la tupla de archivos relacionados.
6.5.3.
Estructura utilizada para identicacin de inconsistencias tras una falla
Esta estructura est formada por tres campos que son los siguientes: Representacin del comienzo de la transaccin. Nmero de registro de la tabla histrica de relaciones procesado. Representacin del nal de la transaccin.
54
6.5.4.
Estructura utilizada para por el proceso de rollback
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.
55
6.5.5.
Modicaciones generales en los Sistemas de archivos
Las modicaciones generales que deben tener los sistemas de archivos para soportar la tcnica planteada en el presente trabajo son las siguientes: Todas las nuevas estructuras planteadas en el punto anterior deben ser ubicadas en regiones de la unidad de almacenamiento reservadas por el sistema de archivos para conocer su ubicacin y poder accederlas. Es necesario tener un id por archivo para poder identicarlo y de esa manera acceder a sus bloques. El sistema de archivos debe poder acceder a un bloque mediante su direccin fsica para marcarlo como libre en el proceso de rollback
56
EVALUACIN ANALTICA Y EXPERIMENTAL DE LA PROPUESTA
7. Evaluacin Analtica y Experimental de la Propuesta

Cuando se accede a un archivo existen tres tiempos intervinientes en la operacin: 1. El tiempo que tardan los cabezales en posicionarse en el cilindro donde se encuentra el sector a leer o escribir
(tiempo de seek).
2. El tiempo de rotacin para que el sector a leer o escribir se encuentre con el cabezal(tiempo 3. El tiempo de lectura o escritura
de latencia).
(tiempo de transferencia).
7.1. Evaluacin analtica

El tiempo de acceso a un archivo puede ser representado con la siguiente expresin[20][21]:
T =
n 0
S (n)
n 0
L (n)
n 0
T (n)
Donde: El subndice
n representa la cantidad de bloques que forman el archivo. tiempos de seek generados por el acceso a todos los bloques que forman el
S (n)
es la sumatoria de los
0 archivo.[20] n
L(n) es la sumatoria de los tiempos de latencia generados por el acceso a todos los bloques que forman
0 el archivo.[20] n
T (n)
es la sumatoria de los
tiempos de transferencia generados por el acceso a todos los bloques que
0 forman el archivo.[20]
7.1.1.
Hiptesis sobre el tiempo de seek tiempo de seek,
Se plantea la siguiente hiptesis sobre el
iN
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 constante que representa el tiempo en trasladarse de un cilindro a otro estando ambos ubicados de manera consecutiva. para la expresin
C (n) representa el nmero de cilindro en el que se encuentra el bloque n, C (n 1) .[21]
lo mismo aplica
7.1.2.
Hiptesis sobre el tiempo de latencia tiempo de latencia,
Se plantea la siguiente hiptesis sobre el
iN
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 constante que representa el tiempo en pasar de un bloque a otro estando ambos ubicados de manera consecutiva. aplica para la expresin
B (n) representa B (n 1) .[21]
el nmero de bloque fsico en el que se encuentra el bloque n, lo mismo
57
7.1.3.
Hiptesis sobre el tiempo de transferencia, tiempo de transferencia,
Planteando la siguiente hiptesis sobre el
i, 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 representar el tiempo de acceso a un archivo
T =
n 0
S (n)
n 0
L ( n)
nK
donde K es una constante que representa el tiempo de transferencia de un bloque. Como
nK
sigue siendo una contante, la expresin se puede simplicar an ms[21]
T =
7.1.4.
n 0
S (n)
n 0
L ( n)
Expresin general del tiempo de acceso
Teniendo en cuenta las hiptesis anteriores sobre los tres tiempos intervinientes en el acceso, el tiempo de acceso a un archivo se puede representar con la siguiente expresin
T =
n 0
Q abs (C (n) C (n 1))
n 0
M abs (B (n) B (n 1))
siendo la expresin denitiva[21]
T =Q
7.1.5.
n 0
abs (C (n) C (n 1))
n 0
abs (B (n) B (n 1))
Grco del tiempo de seek en funcin de la distancia entre cilindros
Como se mencion, la expresin para representar el tiempo de seek es
S (n) = Q abs (C (n) C (n 1))

es una funcin de dos variables (Q es una constante), pero si se toma a expresin queda reducida a una funcin de una variable, es decir
C (n 1)
como una constante P la
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 encuentra el bloque accedido anteriormente (constante P). La expresin
S (n) = Q abs (C (n) P )

es equivalente a la siguiente funcin partida
{ Q (C (n) P ) si S (n) = Q (P C (n)) si
C ( n) P C ( n) < P
58
El grco 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 encuentran los bloques.[21] Cabe hacer la aclaracin de que el valor 5 es a modo de ejemplicacin.
7.1.6.
Grco del tiempo de latencia en funcin de la distancia entre bloques
Como se mencion, la expresin para representar el tiempo de latencia es
L (n) = M abs (B (n) B (n 1))

es una funcin de dos variables (M es una constante), pero si se toma a expresin queda reducida a una funcin de una variable, es decir
B (n 1)
como una constante Z la
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 anteriormente (constante P) independientemente del cilindro en el que se encuentren. La expresin
L (n) = M abs (B (n) Z )

es equivalente a la siguiente funcin partida
{ M (B (n) Z ) si L (n) = M (Z B (n)) si
B ( n) Z B ( n) < Z
59
El grco 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(independientemente de los cilindros en los que se encuentren).[21] Cabe hacer la aclaracin de que el valor 5 es a modo de ejemplicacin. El grco anterior y el que representa 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 de las rectas).
Q y M pueden no qu ser iguales (son las pendientes
7.1.7.
Observaciones nales sobre el tiempo de acceso
La expresin nal del tiempo de acceso a un archivo es
T =Q
n 0
abs (C (n) C (n 1))
n 0
abs (B (n) B (n 1))
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 almacenamiento.
7.2. Evaluacin Experimental

7.2.1. Descripcin 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 congurados. Este
mdulo genera la informacin de las relaciones de archivos (principio de localidad basado en relaciones) y los tiempos de acceso a los mismos.
60
Mdulo LocalityPrinciple: Accede a la cola de relaciones y genera un resultado temporal que respeta el algoritmo presentado en la seccin 6.1.1 Mdulo Merge: Accede a la tabla histrica de relaciones y al resultado temporal generado por el mdulo LocalityPrinciple y realiza el merge entre ambas respetando lo planteado en la seccin 6.1.1 Mdulo Relocation: Realiza la reubicacin de bloques respetando el principio de localidad segn relaciones. Mdulo Orchestrator: Realiza la orquestacin de los mdulos LocalityPrinciple, Merge y Relocation. Mdulo Congurations: Encargado de acceder a las diferentes conguraciones de la simulacin. Mdulo Statics: 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 conguracin, en ella adems, por cada proceso, se especica una lista de archivos a los que debe acceder, a continuacin se ejemplica la conguracin 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 conguracin indica que se deben ejecutar dos procesos, el primer proceso tiene a
id 123, realiza el acceso dos archivos, el primer acceso realizado es al archivo 30, de manera random y accede a 9000 de sus bloques. random o secuencial, el acceso randon ejecuta accesos de manera secuencial implica acceder de manera coonsecutiva a los bloques
El acceso a los archivos puede ser de manera
aleatoria a cualquier de sus bloques, el acceso vuelve a comenzar desde el primer bloque.
del archivo comenzando desde el primero, en caso de que se ejecuten ms accesos que bloques tiene el archivo se
Los archivos existentes en el sistema de archivos simulado se crean a partir de la siguiente conguracin: les.count=2 le.id.0=30 le.blocks.0=1001,9000|1001,9001|1001,9002 le.id.1=31 le.blocks.1=2100,9000|2100,9001|2100,9002|2100,9003|2100,9020|2100,9022 Esta conguracin indica que existen dos archivos, el primero primero de ellos se encuentra en el
id 30, y est compuesto por tres bloques, el cilindro 1001 y en la pista 9000.
La cantidad de cilindros y cantidad de bloques por cilindro que tendr la unidad de almacenamiento simulada (sobre la que se ejecuta el sistema de archivos simulado) se crea a partir de la siguiente conguracin: tracks.count=5000 bloks.by.tracks=10000 Esta conguracin indica que la unidad de almecenamiento tiene
5000 cilindros (o pistas) y 10000 bloques
por cilindro.
61
El mdulo
FileSystem recibe estas conguraciones 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 congurado, 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 localidad platenado en la seccin 6.1.1 Se tomarn las estadsticas de ambas ejecuciones para luego compararlas y obtener conclusiones. Dado que nos interesa analizar los tiempos de acceso de
mdulo Orchestrator para aplicar el principio 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.
62
7.2.2.
Diagrama de arquitectura de la simulacin
63
7.2.3.
Diagrama de secuencia de la simulacin
7.2.4.
Cdigo fuente de mdulo FileSystem
package
t e s i s . c o r e . f i l e s y s t e m . impl ;
64
import import import import
java . u t i l . ArrayList ; java . u t i l . C o l l e c t i o n s ; java . u t i l . List ; j a v a . u t i l . Map ;
import import
org . apache . l o g 4 j . Logger ; org . springframework . beans . f a c t o r y . annotation . Required ;
import import import import import import import
t e s i s . core . f i l e s y s t e m . FileSystem ; t e s i s . core . filesystem . resolver . BlockSelectorResolver ; t e s i s . core . filesystem . resolver . s t r a t e g i e s . BlockSelector ; t e s i s . c o r e . f i l e s y s t e m . r e s o l v e r . s t r a t e g i e s . model . B l o c k S e l e c t o r D a t a ; t e s i s . c o r e . model . f i l e s . B l o c k ; t e s i s . c o r e . model . p r o c e s s . A c c e s s ; t e s i s . c o r e . model . 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 ;
public
class
FileSystemImpl
implements
FileSystem {
final
static
Logger
L O G G E R =
Logger . getLogger ( FileSystemImpl . c l a s s ) ;
private private
BlockSelectorResolver Block currentHeadBlock
blockSelectorResolver ; = n u l l ; / / Current block of head
public
L i s t <Long>
e x e c u t e ( t e s i s . c o r e . model . f i l e s y s t e m . F i l e S y s t e m process , { Map <Long ,
fileSystem , files ,
L i s t < t e s i s . c o r e . model . p r o c e s s . P r o c e s s > RelationshipsQueue relationshipsQueue )
L i s t >
L i s t <Long>
accesTimes
= new
A r r a y L i s t <Long > ( ) ;
int
executionsCount i =0; i <
f i l e S y s t e m . getExecutionsCount ( ) ; i ++){ proc : process ) {
for ( int for
executionsCount ;
( t e s i s . c o r e . model . p r o c e s s . P r o c e s s L i s t <Long> Map <Long , relationshipsFile L i s t <Long> > = new
A r r a y L i s t <Long > ( ) ; = relationshipsQueue . getRelationships () ;
relationships
i f ( r e l a t i o n s h i p s . containsKey ( proc . getId ( ) ) ) { r e l a t i o n s h i p s F i l e . addAll ( r e l a t i o n s h i p s . get ( proc . getId ( ) ) ) ; }
p r o c e s s A l l A c c e s s ( proc . getAccess ( ) ,
accesTimes ,
files ,
relationshipsFile ) ;
i f ( ! r e l a t i o n s h i p s . containsKey ( proc . getId ( ) ) ) { r e l a t i o n s h i p s . put ( p r o c . g e t I d ( ) , }else{ i n s e r t N o t R e p e a t F i l e s I d ( r e l a t i o n s h i p s . get ( proc . getId ( ) ) , } relationshipsFile ) ; relationshipsFile ) ;
C o l l e c t i o n s . s o r t ( r e l a t i o n s h i p s . get ( proc . getId ( ) ) ) ;
L O G G E R. d e b u g ( " P r o c e s i n g concat (" } } of
process
" . c o n c a t ( Long . t o S t r i n g ( p r o c . g e t I d ( ) ) ) .
iteration
") . concat ( I n t e g e r . t o S t r i n g ( i ) ) ) ;
return }
accesTimes ;
private for
void ( Long
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 <Long> fileId : relationshipsFile ) {
r e l a t i o n s h i p s , L i s t <Long>
relationshipsFile )
i f ( ! relationships . contains ( f i l e I d ) ){ r e l a t i o n s h i p s . add ( f i l e I d ) ; } } }
private
void
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 > L i s t > = 0; files ,
access ,
L i s t <Long>
accesTimes , {
Map <Long , long time
L i s t <Long>
relationshipsFiles )
for
( Access
acc
access )
65
time
time
getAccessTime ( acc ,
files ) ;
if ( relationshipsFiAnlisis
de
los
r e s u l t a d o s l e s . indexOf ( acc . 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 ) ) ; }
private long
long time
getAccessTime ( Access = 0; blocks =
access ,
Map <Long ,
files )
L i s t 
f i l e s . get ( access . getFileId () ) ;
i f ( blocks
!=
null ){ blockSelectorData blocks ) ; = new BlockSelectorData (
BlockSelectorData
t h i s . currentHeadBlock ,
BlockSelector
blockSelector
b l o c k S e l e c t o r R e s o l v e r . r e s o l v e ( a c c e s s . getAccessType ( ) ) ;
int
accessCount
a c c e s s . getAccessCount ( ) ;
for ( int
i =0;
<
accessCount ; =
i ++){
Block time =
toBlock time +
blockSelector . s e l e c t ( blockSelectorData ) ; toBlock ) ;
TimesHelper . g e t T r a s la t i o n T i m e ( t h i s . currentHeadBlock , = toBlock ;
t h i s . currentHeadBlock
blockSelectorData . setCurrentBlock ( t h i s . currentHeadBlock ) ; } }
return }
time ;
@Required public void setBlockSelectorResolver ( BlockSelectorResolver = blockSelectorResolver ; blockSelectorResolver ) {
this . blockSelectorResolver } }
7.2.5.
Cdigo fuente de mdulo TimesHelper
package
t e s i s . core . f i l e s y s t e m A n l i s i s
de
los
r e s u l t a d o s . impl ;
import
t e s i s . c o r e . model . f i l e s . B l o c k ;
public
class
TimesHelper
private
final
static
int
FIRST_GLOBAL_ACCESS_TIME = int int C H A N G E _ T R A C K _ T I M E = C H A N G E _ B L O C K _ T I M E = 10; 1;
0;
private private
final final
static static
public
static
long
getTraslationTime ( Block
fromBlock ,
Block
toBlock ) {
i f ( fromBlock return }
= =
n u l l ) {// i s
the
first
global
access
FIRST_GLOBAL_ACCESS_TIME ;
int long
differenceTracks differenceBlocks
= 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 ( ) = 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 . getTrackNumber ( ) ) ; t o B l o c k . getBlockNumber ( ) ) ;
C H A N G E _ B L O C K _ T I M E) ;
return } }
( differenceTracks
C H A N G E _ T R A C K _ T I M E)
( differenceBlocks
7.2.6.
Cdigo fuente de mdulo LocalityPrinciple
package
t e s i s . c o r e . l o c a l i t y p r i n c i p l e . impl ;
import
java . u t i l . ArrayList ;
66
import import import
java . u t i l . C o l l e c t i o n s ; java . u t i l . List ; j a v a . u t i l . Map . E n t r y ;
import
org . apache . l o g 4 j . Logger ;
import import import import import
t e s i s . core . l o c a l i t y p r i n c i p l e . LocalityPrinciple ; t e s i s . c o r e . l o c a l i t y p r i n c i p l e . model . B a s i c R e l a t i o n s h i p ; t e s i s . c o r e . model . 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 ; t e s i s . c o r e . model . 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 ; t e s i s . c o r e . model . 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 p ;
public
class
LocalityPrincipleImpl
implements
LocalityPrinciple {
final
static
Logger
L O G G E R =
Logger . getLogger ( L o c a l i t y P r i n c i p l e I m p l . c l a s s ) ;
public
TemporaryResult
execute ( RelationshipsQueue relationships = new
relationshipsQueue )
L i s t <R e l a t i o n s h i p >
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 Relationship
basicRelationships ;
relationshipTmp ;
int for
iterationIndex ( E n t r y<Long , entrySet () ) L i s t <Long> {
1; relationshipQueue : relationshipsQueue . getRelationships () .
L i s t <Long> >
filesId
relationshipQueue . getValue ( ) ;
i f ( f i l e s I d . size ()
>
1) { = CartesianProductHelper . getCartesianProduct ( f i l e s I d ) ;
basicRelationships
for
( BasicRelationship r e l a t i o n s h i p T m p=new
basicRelationship
basicRelationships )
Relationship ( basicRelationship . getFirstFileId () , 1) ;
basicRelationship . getSecondFileId () ,
int
index
r e l a t i o n s h i p s . indexOf ( relationshipTmp ) ;
i f ( index
= =
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 relationship = r e l a t i o n s h i p s . get ( index ) ;
r e l a t i o n s h i p . s e t R e p e t i t i o n s C o u n t ( r e l a t i o n s h i p . g e t R e p e t i t i o n s C o u n t ( ) +1) ; } } }
iterationIndex }
iterationIndex
1;
Collections . sort ( relationships ) ;
return } }
new
TemporaryResult ( r e l a t i o n s h i p s ) ;
7.2.7.
Cdigo fuente de mdulo CartesianProductHelper
package
t e s i s . c o r e . l o c a l i t y p r i n c i p l e . impl ;
import import
java . u t i l . ArrayList ; java . u t i l . List ;
import
t e s i s . c o r e . l o c a l i t y p r i n c i p l e . model . B a s i c R e l a t i o n s h i p ;
public
class
CartesianProductHelper
public
static
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 <Long> = new
filesId ){
L i s t BasicRelationship
cartesianProduct
A r r a y L i s t ( ) ;
basicRelationshipTmpOne ; basicRelationshipTmpTwo ;
BasicRelationship
for
( Long
fileId
filesId )
67
for
( Long
fileIdTmp !=
filesId )
if ( fileId
fileIdTmp ) { = new = new BasicRelationship ( fileId , fileIdTmp ) ; fileId ) ;
basicRelationshipTmpOne basicRelationshipTmpTwo
B a s i c R e l a t i o n s h i p ( fileIdTmp , & &
i f ( ! c a r t e s i a n P r o d u c t . c o n t a i n s ( basicRelationshipTmpOne )
! c a r t e s i a n P r o d u c t . c o n t a i n s ( 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.
package
Cdigo fuente de mdulo Merge

t e s i s . c o r e . merge . i m p l ;
java . u t i l . ArrayList ; java . u t i l . C o l l e c t i o n s ; java . u t i l . List ;
import import import import
t e s i s . c o r e . m e r g e . Merge ; t e s i s . c o r e . model . 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 ; t e s i s . c o r e . model . 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 T a b l e ; t e s i s . c o r e . model . 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 p ;
public
class
MergeImpl
implements
Merge {
final
static
Logger
L O G G E R =
L o g g e r . g e t L o g g e r ( MergeImpl . c l a s s ) ;
public
RelationsHistoryTable
execute ( RelationsHistoryTable
relationsHistoryTable ,
TemporaryResult {
temporaryResult )
relationsHistory
= new
A r r a y L i s t <R e l a t i o n s h i p > ( ) ;
copyRelationsHistoryTable ( relationsHistoryTable ,
relationsHistory ) ;
i f ( temporaryResult return } new
= =
null
||
temporaryResult . g e t R e l a t i o n s h i p s ( )
= =
null ){
RelationsHistoryTable ( relationsHistory ) ;
L O G G E R. d e b u g ( " C a l l i n g
addTemporaryResult
method " ) ;
addTemporaryResult ( temporaryResult ,
relationsHistory ) ;
L O G 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 ") ;
Collections . sort ( relationsHistory ) ;
return }
new
RelationsHistoryTable ( relationsHistory ) ;
private
void
copyRelationsHistoryTable ( RelationsHistoryTable relationsHistory ) != null & & {
relationsHistoryTable ,
i f ( relationsHistoryTable { for ( Relationship
relationsHistoryTable . getRelationships ()
!=
null )
relationship
relationsHistoryTable . getRelationships () )
r e l a t i o n s H i s t o r y . add ( new
Relationship ( relationship . getFirstFileId () , r e l a t i o n s h i p . getRepetitionsCount () ) ) ;
relationship . getSecondFileId () , } } }
private
void
addTemporaryResult ( TemporaryResult relationsHistory ) {
temporaryResult ,
L i s t <R e l a t i o n s h i p > int index ;
Relationship
relationshipTmp ;
for
( Relationship
relationship
temporaryResult . g e t R e l a t i o n s h i p s ( ) )
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 ( index !=
1) {
68
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 ) ; r e l a t i o n s h i p T m p . s e t R e p e t i t i o n s C o u n t ( r e l a t i o n s h i p T m p . g e t R e p e t i t i o n s C o u n t ( )+ r e l a t i o n s h i p . 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.
package
Cdigo fuente de mdulo Relocation

t e s i s . c o r e . r e l o c a t i o n . impl ;
java . u t i l . ArrayList ; j a v a . u t i l . LinkedHashMap ; java . u t i l . List ; j a v a . u t i l . Map ; j a v a . u t i l . Map . E n t r y ;
import
org . apache . l o g 4 j . Logger ;
t e s i s . c o r e . model . f i l e s . B l o c k ; t e s i s . c o r e . model . f i l e s y s t e m . B l o c k S t a t u s ; t e s i s . c o r e . model . 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 T a b l e ; t e s i s . c o r e . model . 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 p ; t e s i s . core . relocation . Relocation ;
public
class
RelocationImpl
implements
Relocation {
final
static
Logger
L O G G E R =
Logger . getLogger ( RelocationImpl . c l a s s ) ;
public
void
execute ( RelationsHistoryTable L i s t > files ,
relationsHistoryTable , statusBlocks ) {
Map <Long ,
LinkedHashMap
L O G 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 L i s t <Long> optimalFilesOrder =
method " ) ;
getOptimalFilesOrder ( relationsHistoryTable .
getRelationships () ) ;
L O G 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 L i s t optimalBlocksOrder =
method " ) ; files ) ;
getOptimalBlocksOrder ( optimalFilesOrder ,
L O G 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 " ) ; statusBlocks ) ;
r e l o c a t i o n B l o c k s ( optimalBlocksOrder , }
private
L i s t <Long>
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 > = new A r r a y L i s t <Long > ( ) ;
relationships )
L i s t <Long>
optimalFilesOrder
for
( Relationship
relationship
relationships )
i f ( ! optimalFilesOrder . contains ( relationship . getFirstFileId () ) ){ 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 ( ) ) ; }
i f ( ! optimalFilesOrder . contains ( relationship . 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 ;
private
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 <Long> files ) {
optimalFilesOrder ,
Map <Long ,
optimalBlocksOrder
= new
A r r a y L i s t ( ) ;
for
( Long
fileId
optimalFilesOrder )
{ fileId "
L O G G E R. d e b u g ( " method
getOptimalBlocksOrder ,
. 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 ( ) ) ) ;
69
optimalBlocksOrder . addAll ( f i l e s . get ( f i l e I d ) ) ; }
return }
optimalBlocksOrder ;
private
void
r e l o c a t i o n B l o c k s ( L i s t BlockStatus>
optimalBlocksOrder , {
LinkedHashMap = =
block
statusBlocks . entrySet () )
i f ( block . getValue ( ) currentBlock =
B l o c k S t a t u s . FREE) {
optimalBlocksOrder . get ( currentBlockIndex ) ;
c u r r e n t B l o c k . setBlockNumber ( b l o c k . getKey ( ) . getBlockNumber ( ) ) ; c u r r e n t B l o c k . setTrackNumber ( b l o c k . getKey ( ) . getTrackNumber ( ) ) ;
i f ( optimalBlocksOrder . s i z e ( ) return ; }
1 = =
currentBlockIndex ) {
currentBlockIndex } } } }
currentBlockIndex
1;
7.2.10.
Cdigo fuente de mdulo Orchestrator
package
t e s i s . c o r e . o r c h e s t r a t o r . impl ;
j a v a . u t i l . LinkedHashMap ; java . u t i l . List ; j a v a . u t i l . Map ;
import
org . springframework . beans . f a c t o r y . annotation . Required ;
import import import import import import import import import
t e s i s . core . l o c a l i t y p r i n c i p l e . LocalityPrinciple ; t e s i s . c o r e . m e r g e . Merge ; t e s i s . c o r e . model . f i l e s . B l o c k ; t e s i s . c o r e . model . f i l e s y s t e m . B l o c k S t a t u s ; t e s i s . c o r e . model . 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 ; t e s i s . c o r e . model . 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 ; t e s i s . c o r e . model . 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 T a b l e ; t e s i s . core . orchestrator . Orchestrator ; t e s i s . core . relocation . Relocation ;
public
class
OrchestratorImpl
implements
Orchestrator {
private
LocalityPrinciple
localityPrinciple ;
private
Merge
merge ;
private
Relocation
relocation ;
public
void
execute ( RelationshipsQueue
relationshipsQueue , L i s t > files ,
RelationsHistoryTable LinkedHashMap statusBlocks ) {
TemporaryResult
temporaryResult
t h i s . l o c a l i t y P r i n c i p l e . execute ( relationshipsQueue ) ;
r e l a t i o n s H i s t o r y T a b l e . s e t R e l a t i o n s h i p s ( t h i s . merge . e x e c u t e ( r e l a t i o n s H i s t o r y T a b l e , temporaryResult ) . g e t R e l a t i o n s h i p s ( ) ) ; t h i s . r e l o c a t i o n . execute ( relationsHistoryTable , } files , statusBlocks ) ;
70
@Required public void setLocalityPrinciple ( LocalityPrinciple = localityPrinciple ; localityPrinciple ) {
this . localityPrinciple }
@Required public void s e t M e r g e ( Merge = merge ; merge ) {
t h i s . merge }
@Required public void setRelocation ( Relocation = relocation ; relocation ) {
this . relocation } }
7.2.11.
Cdigo fuente de mdulo RandomBlockSelector
package
t e s i s . c o r e . f i l e s y s t e m . r e s o l v e r . s t r a t e g i e s . impl ;
import import
java . u t i l . List ; j a v a . u t i l . Random ;
org . apache . l o g 4 j . Logger ; org . springframework . u t i l . C o l l e c t i o n U t i l s ; t e s i s . core . filesystem . resolver . s t r a t e g i e s . BlockSelector ; t e s i s . c o r e . f i l e s y s t e m . r e s o l v e r . s t r a t e g i e s . model . B l o c k S e l e c t o r D a t a ; t e s i s . c o r e . model . f i l e s . B l o c k ;
public
class
RandomBlockSelector
implements
BlockSelector {
final
static
Logger
L O G G E R =
Logger . getLogger ( RandomBlockSelector . c l a s s ) ;
public
Block
s e l e c t ( BlockSelectorData blocks =
blockSelectorData )
blockSelectorData . getBlocks () ;
i f ( C o l l e c t i o n U t i l s . isEmpty ( b l o c k s ) ) { return } null ;
Random
randomGenerator
= new
Random ( ) ;
int
index
randomGenerator . n e x t I n t ( b l o c k s . s i z e ( ) ) ;
Block
block
blocks . get ( index ) ;
L O G 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
is
for
% s",
block ) ) ;
return } }
block ;
7.2.12.
Cdigo fuente de mdulo SecuentialBlockSelector
package
t e s i s . c o r e . f i l e s y s t e m . r e s o l v e r . s t r a t e g i e s . impl ;
import
java . u t i l . List ;
import import
org . apache . l o g 4 j . Logger ; org . springframework . u t i l . C o l l e c t i o n U t i l s ;
t e s i s . core . filesystem . resolver . s t r a t e g i e s . BlockSelector ; t e s i s . c o r e . f i l e s y s t e m . r e s o l v e r . s t r a t e g i e s . model . B l o c k S e l e c t o r D a t a ; t e s i s . c o r e . model . f i l e s . B l o c k ;
public
class
SecuentialBlockSelector
implements
BlockSelector {
final
static
Logger
L O G G E R =
Logger . getLogger ( S e c u e n t i a l B l o c k S e l e c t o r . c l a s s ) ;
71
public
Block
s e l e c t ( BlockSelectorData = =
blockSelectorData )
Block
currentBlock blocks
blockSelectorData . getCurrentBlock () ; blockSelectorData . getBlocks () ;
i f ( C o l l e c t i o n U t i l s . isEmpty ( b l o c k s ) ) { L O G G E R. d e b u g ( " empty return } null ; l i s t a ") ;
i f ( currentBlock
= =
null ){ is n u l l ") ;
L O G G E R. d e b u g ( " c u r r e n t B l o c k return } blocks . get (0) ;
int
index
b l o c k s . indexOf ( currentBlock ) ;
i f ( index
= =
1) {
is blocks . get (0) ;
L O G 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 return }
for
% s",
currentBlock ) ) ;
index
index
1;
i f ( index
= =
b l o c k s . s i z e ( ) ) { / / End
of
collections block of collection for % s", currentBlock ) ) ;
L O G G E R. d e b u g ( S t r i n g . f o r m a t ( " l a s t return } blocks . get (0) ;
return } }
blocks . get ( index ) ;
7.2.13.
Anlisis comparativos de los resultados
Para la simulacin se utiliz una unidad de almacenamiento 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 presenta a continuacin:
Cantidad de archivos Cantidad de bloques utilizados Porcentaje bloques utilizados
50 archivos 1353 bloques 6,76
El set de prueba de procesos se presenta a continuacin:
72
Cantidad de procesos 50 archivos accedidos
2500 procesos 5476 accesos a archivos. 1358105 dos. bloques accedi-
5000 procesos 10884 accesos a archivos. 2725149 dos. 23098 accesos a archivos. 5746391 dos. 48194 accesos a archivos. 12016780 bloques accedidos. 72925 accesos a archivos. 18181950 bloques accedidos. 98296 accesos a archivos. 24530694 bloques accedidos. bloques accedibloques accedi-
7500 procesos 16575 accesos a archivos. 4121996 dos. 34694 accesos a archivos. 8669868 dos. 71513 accesos a archivos. 17773626 bloques accedidos. 109275 accesos a archivos. 27200785 bloques accedidos. 147302 accesos a archivos. 36724859 bloques accedidos. bloques accedibloques accedi-
100 archivos accedidos
11583 accesos a archivos. 2884391 dos. bloques accedi-
48084 accesos a archivos. 11988251 bloques accedidos.
Se generar un set de datos que represente diferentes cargas de bloques de la unidad de almacenamiento, as como diferentes cantidades de procesos que realizan accesos, el n es obtener resultados para diferentes escenarios y poder analizar los resultados obtenidos.
73
Ejecucin de 2500 procesos:
50 archivos en la unidad de almacenamiento:
74
75
76
77
78
[20]
79
[20]
80
81
82
83
84
85
86
87
88
7.2.14.
Resumen de los resultados obtenidos
A continuacin se exponen tablas que representan las mejoras obtenidas mediante la aplicacin de la nueva poltica de relaciones basadas en el principio de localidad:
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
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
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
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 considerablemente, adems se observa en los grcos 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.
89
CONCLUSIN
8. Conclusin
8.1. Anlisis de los resultados
En este trabajo se present una nueva poltica para la administracin de los bloques pertenecientes a los archivos, la misma se basa en relacionar todos los archivos accedidos por el mismo proceso. El objetivo de esta nueva poltica es mejorar los tiempos de acceso, para esto se reubican los bloques de los archivos respetando el
principio de localidad de archivos asociados.
Se efectu un anlisis cualtitativo para analizar el impacto de esta tcnica con respecto a la no implementacin de la misma, los resultados obtenidos arrojaron que la implementacin 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 trabajos de investigacin sobre problemas para atacar en los sistemas de archivos, el campo de investigacin es muy grande.
90
CONCLUSIN
8.2. Trabajos futuros

Como trabajos futuros se proponen los siguientes temas: 1. Investigar alternativas para obtener una buena poltica de reubicacin de bloques. 2. Investigar alternativas 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 importante para incrementar la performance de la tcnica, mientras la reubicacin se realice de manera ms inteligente, 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 interesante para abordar es la investigacin de los campos especcos en los que la aplicacin de esta tcnica incrementa 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 seguramente ocurra lo contrario. La investigacin y posterior implementacin de estos trabajos futuros van a generar que la tcnica sea ms segura y ms efectiva. Como se observa, el campo de investigacin es muy mplio.
91
NDICE ALFABTICO
9. ndice alfabtico
Agrupacin por cilindros, 33 Algoritmo de principio de localidad en archivos asociados, 44 Allocate-on-ush, 37 Asignacin de bloques, 8 Buer-cache, 38 Buering, 24 Cache, 13 Colas mltiples de reemplazo para el segundo nivel de buer-cache, 41 DataBlocks, 22 Delayed allocation, 33 Desfragmentacin, 31 Directorios, 23 Fragmentacin, 30 FAT, 17 Hierarquical File System, 26 HPFS, 28 Lectura adelantada de bloques, 13 Lista enlazada de unidades de almacenamiento libres, 11 Mapa de bits, 11 Mecanismo de log para mantener la consistencia en caso de falla, 51 Nodos-i, 10 NTFS, 18 POSIX, 16 preallocate, 37 Principio de localidad, 30 Reduccin del movimiento del brazo del disco, 13 Seguridad, 12
92
NDICE ALFABTICO
Sistema de archivos, 7 Sistemas de archivos por bitcora, 15 Sistemas de archivos virtuales, 15 Tablas del kernel, 23 Tabla histrica de relaciones, 54 ZFS, 28
93
10
REFERENCIAS
10. Referencias
[1]Andrew S. Tanenbaum. Sistemas operativos modernos. [2]Apuntes de la materia organizacin de datos. [3]http://www.tldp.org/HOWTO/Filesystems-HOWTO-7.html#hfs [4]http://developer.apple.com/legacy/mac/library/documentation/mac/MoreToolbox/MoreToolbox-11.html [5]http://pages.cs.wisc.edu/~legault/miniproj-736.pdf [6]http://kernelnewbies.org/Ext4#head-38e6ac2b5f58f10989d72386e6f9cc2ef7217fb0 [7]http://www.ibm.com/developerworks/linux/library/l-ext4/ [8]http://hub.opensolaris.org/bin/view/Community+Group+zfs/docs [9]http://www.ibm.com/developerworks/linux/library/l-anatomy-ext4/ [10]http://technet.microsoft.com/en-us/library/cc778290(WS.10).aspx [11]Johns Hopkings university, Ext3cow: A Time-Shifting File System for Regulatory Compliance http://hssl.cs.jhu.edu/~zachary/papers/peterson-tos05.pdf [12]A Fast File System for UNIX, university of California http://www.cs.berkeley.edu/~brewer/cs262/FFS.pdf [13]"Intelligent methods for le system optimization, Leo Kuvayev university of Massachusetts" http://clgiles.ist.psu.edu/papers/AAAI-97.intelligent.le.organization.pdf [14]"Ext4, btrfs, and the others, Jan Kra" http://atrey.karlin.m.cuni.cz/~jack/papers/lk2009-ext4-btrfs.pdf [15]"The new ext4 lesystem: current status and future plans, IBM Linux Technology Center" http://kernel.org/doc/ols/2007/ols2007v2-pages-21-34.pdf [16]The eects of age and fragmentation on le system performance, Harvard university http://www.eecs.harvard.edu/~keith/research/tr94.html [17]Design algorithms for asynchronous write operations in disk-buer-cache memory, AT&T Bell Laboratories, Naperville, Illinois, USA [18]A Better Update Policy, Jerey C. Mogul, Digital Equipment Corporation Western Research Laboratory [19]The MultiQueue replacement algorithm for second level buer caches, Yuanyuan Zhou and James F. Philbin, Princeton university [20]Average seek time of a computer disk, Computer Science Department, SUNY/Plattsburgh, http://faculty.plattsburgh.edu/jan.plaza/teaching/papers/seektime.html [21]File Structures, Zoellick y Folk
94

Tes Is Leguizamo

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Tes Is Leguizamo

Diunggah oleh

Hak Cipta:

Format Tersedia

Tesis de grado de Ingeniera en informtica

Sistemas de Archivos.Tendencias y mejoras tecnolgicas

Universidad de Buenos Aires Facultad de Ingeniera Departamento de Computacin

Seguridad 4.4.1. 4.4.2. 4.4.3.

Rendimiento del sistema de archivos Uso de cache Lectura adelantada de bloques

Reduccin del movimiento del brazo del disco . . . . . . . . . . . . . . . . . . . . . . . . . .

5. Relevamiento bibliogrco de mtodos y tendencias para optimizar el rendimiento de sistemas de archivo 30

Buer-cache para la optimizacin de tiempos de acceso . . . . . . . . . . . . . . . . . . . . . . . . .

Tesis de grado de ingeniera en informtica.

5.4.3. 5.4.4. 5.4.5. 5.4.6.

Colas mltiples de reemplazo para el segundo nivel de buer-cache . . . . . . . . . . . . . .

6. Elaboracin de una propuesta de solucin alternativa o superadora

Resultado de la reubicacin de archivos segn las relaciones . . . . . . . . . . . . . . . . . .

Heurstica para la ejecucin del mdulo de orquestacin

Mecanismo de log para mantener la consistencia en caso de falla

7. Evaluacin Analtica y Experimental de la Propuesta

Cdigo fuente de mdulo Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tesis de grado de ingeniera en informtica.

9. ndice alfabtico 10.Referencias

Tesis de grado de ingeniera en informtica.

John Lennon, 1971

Tesis de grado de ingeniera en informtica.

mentaria para atacar los problemas detectados.

La cuarta etapa consiste en la evaluacin analtica y/o experimental de la propuesta.

Tesis de grado de ingeniera en informtica.

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

Favio, Dani y Jos.

Tesis de grado de ingeniera en informtica.

sistema de archivos, que es el tema de la tesis.

Tesis de grado de ingeniera en informtica.

RELEVAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4. Relevamiento bibliogrco sobre sistemas de archivos

Tesis de grado de ingeniera en informtica.

RELEVAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

Asignacin por lista enlazada

Asignacin por lista enlazada utilizando una tabla en memoria

Tesis de grado de ingeniera en informtica.

RELEVAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

Tesis de grado de ingeniera en informtica.

RELEVAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4.2. Administracin de espacio libre

mapa de bits o una lista

enlazada de unidades de almacenamiento libres. 4.2.1. Administracin mediante mapa de bits

Tesis de grado de ingeniera en informtica.

RELEVAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

Administracin mediante lista enlazada de unidades de almacenamiento libres

4.4. Rendimiento del sistema de archivos

Tesis de grado de ingeniera en informtica.

RELEVAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

FIFO (cola), etctera. [1]

Lectura adelantada de bloques

Reduccin del movimiento del brazo del disco

4.5. Implementacin de directorios

Tesis de grado de ingeniera en informtica.

RELEVAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

4.6. Nuevas prestaciones en sistemas de archivos

Tesis de grado de ingeniera en informtica.

RELEVAMIENTO BIBLIOGRFICO SOBRE SISTEMAS DE ARCHIVOS

Sistemas de archivos estructurados por registro

i-nodos (en el caso de unix), bloques de

directorios, bloques de archivos, etc.[1]

Sistemas de archivos por bitcora

Sistemas de archivos virtuales sistema de archivos virtual (VFS) es integrar

5. Relevamiento bibliogrco de mtodos y tendencias para optimizar el rendimiento de sistemas de archivo 30

Buer-cache para la optimizacin de tiempos de acceso . . . . . . . . . . . . . . . . . . . . . . . . .

Colas mltiples de reemplazo para el segundo nivel de buer-cache . . . . . . . . . . . . . .

madre y a mi madrina por el sacricio y la ayuda que me dieron siempre, gracias.

4. Relevamiento bibliogrco sobre sistemas de archivos

volumen se utilizan para identicar el volumen.

relevamiento bibliogrco y tendencias tecnolgicas.

i-nodo, esta estructura es de tamao jo

Allocate-on-ush, esta consiste en retrasar

allocation le. 32 bits, con esto se termina la limitacin

catalog le (B*) son de mayor tamao.

atributes le para direccionar atributos, este archivo es

startup le, que es utilizado para sistemas de archivos

5. Relevamiento bibliogrco de mtodos y tendencias para optimizar el rendimiento de sistemas de archivo