1 of 11

file

system

syst

formato

programa

¿Qué es un filesystem?

Un sistema de archivos es el mecanismo por el cual se organizan los datos (archivos/directorios) en dispositivos de almacenamiento. Proporciona procedimientos para almacenar, recuperar y actualizar dichos datos, y gestiona el espacio libre del dispositivo.

Los sistemas de archivos permiten al usuario interpretar bytes guardados en un disco, consumirlos, escribirlos. Sin un filesystem la información contenida en un disco se vería como un “choclo” gigante de bytes y no podríamos diferenciar, por ejemplo, donde empieza y termina un archivo.

Pero, ¿cómo lo hace? En primer lugar, cada filesystem especifica un formato con el cual los archivos y directorios son almacenados en forma de bytes dentro del dispositivo. En segundo lugar, existen “programas” que basados en ese formato especificado, posibilitan al usuario realizar operaciones con los archivos y directorios de determinado disco respetando el formato especificado.

2 of 11

estado	nombre	...	bloque inicial
1	foto.jpg	...	15
1	carta.txt	...	1
...	...	...	...

en OSADA

...

26	5	4			FFFFFFFF
	FFFFFFFF	12

1

0

..

5

..

3 of 11

file

system

syst

distribuido

syst

servidor

cliente

4 of 11

nuevo

sistema

de archivos

fuse

/home/utnso/mnt/...

listar

leer

crear

programa 1

programa 2

Mi implementación

fuse

create(...)

readdir(...)

read(...)

getattr(...)

shell

¿Y si quiero crear mi propio sistema de archivos?

Los filesystems que entiende el SO están implementados en el Kernel, y si quisiéramos crear el nuestro tendríamos que editar código del mismo. Para evitar esto, podemos usar FUSE. ¿FUSE? FUSE consta de una biblioteca de usuario y un módulo de Kernel que nos permiten montar nuestro propio sistema de archivos en espacio de usuario sin necesidad de meternos con el código del kernel. ¿Cómo funciona? Todas las peticiones realizadas sobre el punto de montaje del filesystem (ls, cat, mkdir, etc) que le llegan al SO son delegadas al programa principal que está implementando fuse. Por ejemplo, si tengo mi filesystem fuse montado en /home/utnso/mnt y algún programa quiere ejecutar un ls (listar archivos/directorios) en ese directorio, entonces esta solicitud será resuelta mediante la función readdir que nosotros habremos implementado en nuestro código. Esta función es una de las que forman parte de la interfaz que nos pide fuse que respetemos. En consecuencia, lo que sea que queramos decir -programar en la función readdir- que hay en /home/utnso/mnt va a ser válido: puedo mentir, diciéndole que existen archivos que en verdad no hay, o puedo responder lo que se me antoje siempre y cuando respete la interfaz que fuse me pide.

5 of 11

./pokedex_cliente /mnt/pokedex

./mapa CiudadVerde /mnt/pokedex

mapa

pokedex cliente

SO

“leer /mnt/pokedex/Mapas/CiudadVerde/metadata”

pokedex

servidor

disco.bin

En el caso del TP de este cuatrimestre, el proceso que sabe todo lo que hay en el disco.bin formateado con el filesystem OSADA y que puede escribir en él, es el Pokedex Servidor. Por lo tanto, cada función de fuse que implementemos para leer/escribir en el filesystem del lado del Pokedex Cliente va a tener que comunicarse con el proceso servidor para poder hacerlo.

Por su parte el Pokedex Servidor va a tener que saber como responder a cada una de las solicitudes que le envíe el Pokedex Cliente, encargándose de mantener las estructuras administrativas del filesystem OSADA, teniendo en cuenta que puede recibir solicitudes de manera concurrente por varios clientes. El Pokedex Servidor, es en definitiva el proceso al que le va a importar la especificación del sistema de archivos: es el que interactúa con el disco formateado.

6 of 11

¡¡ ESTRUCTURAS ADMINISTRATIVAS !!

consumen bloques libres

pokedex

cliente

entrenador1

“copiar medalla”

pokedex

cliente

entrenador2

“copiar pokemon”

pokedex

cliente

shell

“echo hola hola > archivo.txt”

pokedex

servidor

disco.bin

¿Por qué es importante mantener correctamente las estructuras administrativas?

Formatear un disco con determinado sistema de archivos implica crear en el disco las estructuras administrativas necesarias para interpretar dicho filesystem. Es por esto que al formatear un disco de tamaño X el espacio disponible siempre termina siendo menor que el volumen total de almacenamiento: las estructuras administrativas del filesystem son guardadas en el disco junto con los datos.

Además estas estructuras son las que nos van a permitir saber por qué bloques están formados todos los archivos del filesystem, qué bloques de datos tengo disponibles, qué directorios y archivos se encuentran en determinado directorio, etc.

Si, por ejemplo, alguien quisiera escribir un archivo y necesita para eso un nuevo bloque de datos, podríamos buscar alguno disponible en la estructura del bitmap. Una vez que lo encuentro, debería en principio actualizar el bitmap para marcar ese bloque como ocupado y actualizar la tabla de asignaciones para agregar ese nuevo bloque como componente del archivo. Las consecuencias de no hacer estas actualizaciones implicarían por un lado, la posibilidad de asignar ese mismo bloque de datos a otro archivo, escribir encima, perder los datos. Por otro lado, si luego quisiéramos leer el archivo, al recorrer la tabla de asignaciones no seríamos capaces de encontrar el nuevo bloque que compone al archivo.

7 of 11

demo-fuse

syst

8 of 11

fusework

flow

9 of 11

Aplicación

Kernel

Memoria

Planificador

Subsistema de Archivos

VFS

FAT32

EXT4

...

10 of 11

getdents()

FAT32

EXT4

EXT3

getdents()

User

Kernel

FUSE

osada

readdir()

ls

VFS

1 of 11

2 of 11

3 of 11

4 of 11

5 of 11

6 of 11

7 of 11

8 of 11

9 of 11

10 of 11

11 of 11