universidad politecnica de madrid´ -...

UNIVERSIDAD POLITECNICA DE MADRIDFACULTAD DE INFORMATICA

TRABAJO FIN DE CARRERA

Sistema de escrituras volatiles para Linux

AUTOR: Rafael Antonio Porras SamaniegoTUTOR: Fernando Perez Costoya

Esta obra esta bajo una licencia Reconocimiento-No comercial-Sin obras derivadas2.5 Espana de Creative Commons. Para ver una copia de esta licencia, visitehttp://creativecommons.org/licenses/by-nc-nd/2.5/es/o envie una carta a Creative Commons, 171 Second Street, Suite 300, San Francisco,California 94105, USA.

I

A mis padres, Rafael y Marıa del Carmen.A mis hermanos, Mamen y Gonzalo.

Y a todos mis amigos, dentro y fuera de la FI.

III

Indice general

1. INTRODUCCION Y OBJETIVOS 11.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1. Software de clonado de disco . . . . . . . . . . . . . . . . . . . 31.2.2. Restaurar sistema en Windows XP . . . . . . . . . . . . . . . . . 41.2.3. Maquina virtual de sistema con instantaneas de estado . . . . . . 61.2.4. “Instantaneas” y “clones” en ZFS . . . . . . . . . . . . . . . . . 71.2.5. BranchFS en SkyOS . . . . . . . . . . . . . . . . . . . . . . . . 81.2.6. Software de proteccion . . . . . . . . . . . . . . . . . . . . . . . 91.2.7. Hardware de proteccion . . . . . . . . . . . . . . . . . . . . . . 10

1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4. Estructura del libro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2. PLANTEAMIENTO DE SOLUCIONES 152.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2. Propuestas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1. Modificacion de un sistema de ficheros . . . . . . . . . . . . . . 162.2.2. Adaptar el sistema de memoria virtual . . . . . . . . . . . . . . . 202.2.3. Intercepcion de la capa de E/S de bloques . . . . . . . . . . . . . 232.2.4. Dispositivo virtual . . . . . . . . . . . . . . . . . . . . . . . . . 25

3. CONCEPTOS PRELIMINARES 273.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3. Manejo de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4. Informar al usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5. Gestion de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6. Concurrencia y condiciones de carrera . . . . . . . . . . . . . . . . . . . 33

3.6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.6.2. Semaforos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6.3. Spin lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

IV

4. DESARROLLO E IMPLEMENTACION DE LA SOLUCION 374.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2. Creacion del dispositivo virtual . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.1. Estructura de modulo . . . . . . . . . . . . . . . . . . . . . . . . 384.2.2. Registro del dispositivo . . . . . . . . . . . . . . . . . . . . . . . 404.2.3. Disco virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.4. Cola de peticiones . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.5. Control de entrada y salida . . . . . . . . . . . . . . . . . . . . . 504.2.6. Miscelanea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.3. Logica del mapeo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3.1. Tratamiento clasico de una peticion E/S . . . . . . . . . . . . . . 604.3.2. Tratamiento de la peticion de E/S por parte de la solucion . . . . 654.3.3. Modificacion y/o fragmentacion de una peticion BIO . . . . . . . 70

5. CARACTERISTICAS OPCIONALES 755.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2. Consumo de memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.3. Sincronizacion de dispositivos . . . . . . . . . . . . . . . . . . . . . . . 775.4. Estadısticas de acceso al dispositivo . . . . . . . . . . . . . . . . . . . . 78

5.4.1. Estructura del fichero diskstats . . . . . . . . . . . . . . . . . . . 795.4.2. Estructura disk stats . . . . . . . . . . . . . . . . . . . . . . . . 805.4.3. Macro disk stat add . . . . . . . . . . . . . . . . . . . . . . . . 815.4.4. Macro disk stat inc . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.5. Soporte para blktrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.6. Cache de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.7. Utilizacion de macros de Linux . . . . . . . . . . . . . . . . . . . . . . . 865.8. Integracion con el sistema de compilacion del nucleo Linux . . . . . . . . 88

6. CONCLUSIONES Y FUTURAS LINEAS 916.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.2. Futuras lıneas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.3. Estadısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

BIBLIOGRAFIA 97

A. INSTRUCCIONES DE COMPILACION Y USO 99A.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99A.2. Dispositivo virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

A.2.1. Compilacion e instalacion . . . . . . . . . . . . . . . . . . . . . 99A.2.2. Inicializacion del modulo . . . . . . . . . . . . . . . . . . . . . . 100

A.3. Aplicacion de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100A.3.1. Compilacion e instalacion . . . . . . . . . . . . . . . . . . . . . 100A.3.2. Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

A.4. Script de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

V

B. HERRAMIENTAS UTILIZADAS 107B.1. Software libre o de codigo abierto . . . . . . . . . . . . . . . . . . . . . 107B.2. Software privativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

VI

Indice de figuras

1.1. Norton Ghost 14.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Restaurar sistema en Windows XP. . . . . . . . . . . . . . . . . . . . . . 51.3. Gestion de instantaneas en VMware Workstation. . . . . . . . . . . . . . 61.4. HDGUARD en Windows XP. . . . . . . . . . . . . . . . . . . . . . . . . 101.5. Tarjeta PCI WinSchool Safety Card. . . . . . . . . . . . . . . . . . . . . 11

2.1. Diagrama de sistemas de Linux. . . . . . . . . . . . . . . . . . . . . . . 152.2. Estructura de una particion Ext2 y de su grupo de bloques. . . . . . . . . 172.3. Modificacion propuesta: Ext2. . . . . . . . . . . . . . . . . . . . . . . . 182.4. Modificacion propuesta: Ext2 y el sistema de memoria virtual. . . . . . . 202.5. Traduccion de una direccion de memoria virtual a una direccion fısica. . . 212.6. Relacion entre los bloques, las paginas, el soporte y los buffer head. . . . 222.7. Modificacion propuesta: Ext2 y la etapa de E/S. . . . . . . . . . . . . . . 232.8. Modificacion propuesta: dispositivo virtual. . . . . . . . . . . . . . . . . 25

4.1. Transicion entre estados del controlador. . . . . . . . . . . . . . . . . . . 594.2. Bloques, segmentos y paginas. . . . . . . . . . . . . . . . . . . . . . . . 614.3. Relacion de los distintos BIO con sus segmentos y bloques. . . . . . . . . 624.4. Ejemplo de subzona: bloques NO MAPEADO y bloques mapeados. . . . 664.5. Ejemplo de subzona: bloques mapeados consecutivos y no consecutivos. . 674.6. Fragmentacion de un BIO en tres miniBIO. . . . . . . . . . . . . . . . . 694.7. Ejemplo de BIO con tres segmentos que ocupan cada uno una pagina

completamente y que seran utilizados en la transferencia. . . . . . . . . . 704.8. Creacion de un BIO que requiere de un segmento y medio de los disponibles. 714.9. Creacion de un BIO que requiere de medio segmento de los disponibles. . 714.10. Creacion de un BIO que requiere del ultimo segmento disponible. . . . . 72

5.1. Mapa con una estructura de dos niveles. . . . . . . . . . . . . . . . . . . 76

6.1. Grafica correspondiente a la evolucion de las lıneas de codigo de la solucion. 94

VII

Indice de listados

3.1. Asignar y liberar memoria. . . . . . . . . . . . . . . . . . . . . . . . . . 293.2. Niveles de alerta para printk. . . . . . . . . . . . . . . . . . . . . . . . . 313.3. Ejemplo sin goto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4. Ejemplo con goto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.5. Operar con semaforos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6. Operar con semaforos lectura/escritura. . . . . . . . . . . . . . . . . . . 353.7. Operar con spinlock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.8. Operar con spinlock lectura/escritura. . . . . . . . . . . . . . . . . . . . 364.1. Esqueleto de codigo del modulo . . . . . . . . . . . . . . . . . . . . . . 394.2. Ejemplo de modinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3. Extracto del directorio /dev . . . . . . . . . . . . . . . . . . . . . . . . . 414.4. Funcion de registro del dispositivo de bloques. . . . . . . . . . . . . . . . 414.5. Registro del dispositivo de bloques. . . . . . . . . . . . . . . . . . . . . 424.6. Estructura gendisk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.7. Plantilla de operaciones de un dispositivo de bloques. . . . . . . . . . . . 444.8. Creacion y destruccion del dispositivo. . . . . . . . . . . . . . . . . . . . 454.9. Metodo open del dispositivo. . . . . . . . . . . . . . . . . . . . . . . . . 464.10. Metodo release del dispositivo. . . . . . . . . . . . . . . . . . . . . . . . 464.11. Metodo getgeo del dispositivo. . . . . . . . . . . . . . . . . . . . . . . . 474.12. Gestion de colas de dispositivo. . . . . . . . . . . . . . . . . . . . . . . . 494.13. Creacion de una cola de dispositivo. . . . . . . . . . . . . . . . . . . . . 504.14. Pagina ioctl del manual del programador de Linux . . . . . . . . . . . . . 514.15. Funcion ioctl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.16. Comandos ioctl definidos en el fichero map.h. . . . . . . . . . . . . . . . 524.17. Macros para la creacion de ioctl. . . . . . . . . . . . . . . . . . . . . . . 534.18. Acceso a memoria del espacio del usuario. . . . . . . . . . . . . . . . . . 544.19. Ioctl RBD INFO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.20. Ioctl RBD CREATE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.21. Ioctl RBD DELETE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.22. Ioctl RBD RUN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.23. Ioctl RBD STOP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.24. Ioctl RBD RESET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.25. Ioctl RBD SYNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.26. Ioctl RBD VERSION. . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.27. Comprobacion de permisos. . . . . . . . . . . . . . . . . . . . . . . . . 57

IX

4.28. Estructura con informacion de la instancia del dispositivo. . . . . . . . . 584.29. Estructura de un bio vec. . . . . . . . . . . . . . . . . . . . . . . . . . . 614.30. Estructura BIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.31. Estructura que relaciona un BIO con varios miniBIO. . . . . . . . . . . . 724.32. Manipulacion de estructuras BIO. . . . . . . . . . . . . . . . . . . . . . 735.1. Ejemplo de fichero /proc/diskstats. . . . . . . . . . . . . . . . . . . . . . 795.2. Ejemplo de fichero /sys/block/hda/stat. . . . . . . . . . . . . . . . . . . . 795.3. Ejemplo de fichero /sys/block/hda/hda1/stat. . . . . . . . . . . . . . . . . 795.4. Estructura disk stats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.5. Funcion disk stat add. . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.6. Actualizacion de estadısticas. . . . . . . . . . . . . . . . . . . . . . . . . 825.7. Funcion disk stat inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.8. Funciones de blktrace. . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.9. Uso de blk add trace remap. . . . . . . . . . . . . . . . . . . . . . . . . 845.10. Uso de blk add trace bio. . . . . . . . . . . . . . . . . . . . . . . . . . . 845.11. Gestion de la cache de BIO. . . . . . . . . . . . . . . . . . . . . . . . . 855.12. Gestion de la cache de objetos. . . . . . . . . . . . . . . . . . . . . . . . 865.13. Macro bio data dir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.14. Macros bio iovec dix y bio sectors. . . . . . . . . . . . . . . . . . . . . 875.15. Macros likely y unlikely. . . . . . . . . . . . . . . . . . . . . . . . . . . 875.16. Ejemplo de uso de la macro unlikely. . . . . . . . . . . . . . . . . . . . . 875.17. Fichero Kconfig del controlador. . . . . . . . . . . . . . . . . . . . . . . 885.18. Fichero Makefile del controlador. . . . . . . . . . . . . . . . . . . . . . . 89A.1. Aplicar el parche a los fuentes de Linux 2.6.24 . . . . . . . . . . . . . . 99A.2. Dispositivos creados en /dev/ usando el valor 3 con el parametro max rbd. 100A.3. Salida por pantalla de rbdctl sin opciones. . . . . . . . . . . . . . . . . . 101A.4. rbdctl: uso del parametro “-c”. . . . . . . . . . . . . . . . . . . . . . . . 102A.5. rbdctl: uso del parametro “-r”. . . . . . . . . . . . . . . . . . . . . . . . 102A.6. rbdctl: uso del parametro “-i”. . . . . . . . . . . . . . . . . . . . . . . . 103A.7. rbdctl: uso del parametro “-s”. . . . . . . . . . . . . . . . . . . . . . . . 103A.8. rbdctl: uso del parametro “-d”. . . . . . . . . . . . . . . . . . . . . . . . 103A.9. rbdctl: uso del parametro “-0”. . . . . . . . . . . . . . . . . . . . . . . . 104A.10.rbdctl: uso del parametro “-y”. . . . . . . . . . . . . . . . . . . . . . . . 104A.11.rbdctl: uso del parametro “-v”. . . . . . . . . . . . . . . . . . . . . . . . 104

X

Capıtulo 1

INTRODUCCION Y OBJETIVOS

1.1. IntroduccionEn el dıa a dıa, los usuarios de ordenador se ven obligados muchas a veces a realizar

cambios en el software que utilizan. Estos cambios pueden afectar seriamente a la estabi-lidad del equipo, reduciendo incluso su rendimiento. Otras veces, los usuarios ni siquierason conscientes de que han realizado acciones que han puesto en peligro su equipo. Lasiguiente lista contiene una serie de ejemplos que ilustraran mejor estas situaciones:

Instalacion y/o desinstalacion de software: el continuo instalar y desinstalar sof-tware, sobre todo para necesidades puntuales, puede generar un sistema bastantepesado por la cantidad de ficheros olvidados por toda la unidad, entradas inutiles enel registro del sistema, etc.

Actualizacion del software existente: las actualizaciones pueden fallar durante elproceso dejando la aplicacion que se actualizaba en un estado inconsistente. Puedeser incluso necesaria una reinstalacion de la misma. Si la actualizacion que falla esdel Sistema Operativo (a partir de ahora, SO), la unica solucion podrıa ser reinsta-larlo.

Cambios en la configuracion del software: las modificaciones en los ficheros deconfiguracion de cualquier software ya sea para modificar su comportamiento opara afinar su rendimiento, si no se tiene cuidado, pueden dar lugar a que el mismodeje de funcionar correctamente. Y no siempre es facil recordar todos los cambiosefectuados o hacer copias de los ficheros involucrados, siendo necesario restauraruna copia de seguridad.

Borrado accidental de archivos: al administrar un equipo es posible equivocarse yeliminar ficheros vitales del sistema o de una aplicacion, dejando el equipo inutili-zado para el trabajo. Es necesario restaurar una copia de seguridad.

Formateo accidental de un sistema de ficheros: bastante menos probable que el casoanterior, pero aun ası factible. La unica solucion es restaurar una copia de seguridad.

1


Corrupcion del sistema de ficheros: un apagon, si no se dispone de un sistema dealimentacion ininterrumpida, o un fallo hardware, pueden dejar al SO en un estadoinconsistente que no permita su reinicio. Dependiendo de si el fallo afecta al SO oa las aplicaciones, podrıa ser necesario reinstalar el SO o las aplicaciones fallidas,respectivamente.

Infeccion por virus, spyware1, adware2 y demas malware3: a causa de las vulnera-bilidades del software, es probable que un equipo sea “invadido” por este tipo desoftware. Eliminarlos puede ser una tarea ardua y a veces es mas rapido partir deuna copia de seguridad que contenga un sistema limpio.

Cualquiera de estos casos supondrıa una perdida de tiempo y recursos muy valiosospara cualquier organizacion, sea una empresa u otro tipo de institucion. Incluso para unusuario normal, en el entorno de su hogar, serıa una molestia y un inconveniente perderdatos o tener que reinstalar su equipo.

Por tanto, el objetivo de este trabajo es paliar en la medida de lo posible estos proble-mas, evitando completamente sus consecuencias cuando sea posible. Para ello, se modifi-cara el SO Linux para que todas las operaciones realizadas sobre una particion montada nosean permanentes. Cuando se reinicie el equipo, los cambios desapareceran pero mientrasel usuario trabaje, los cambios deberan almacenarse como se harıa en un sistema normal.Tambien sera posible deshacer las escrituras inmediatamente por medio de una aplicacionespecial sin tener que reiniciar.

El alcance de este Trabajo Fin de Carrera (TFC) y los objetivos que debe cumplir seestableceran en el punto 1.3, despues de analizar las soluciones disponibles actualmente,aunque sean para otras plataformas distintas de Linux. Ası, analizando los pros y loscontras de cada solucion, sera mas facil elaborar una lista de requisitos mınimos que elTFC debe cumplir ademas de anadir otros de tipo secundario u opcional.

Las ventajas de un desarrollo de este tipo son evidentes. A partir de la lista de casosanteriores se puede deducir que una vuelta al estado anterior de la particion, esto es, almomento en el que se inicio el equipo para trabajar, solucionarıa casi todos los problemasenumerados. Ademas, hay ciertas ventajas derivadas de este sistema. He aquı algunosejemplos:

Los cibercafes podrıan mantener siempre intacto el SO y las aplicaciones instaladas.Una vez que el usuario termine de utilizar el equipo, basta con reiniciar para tenerun entorno limpio, como recien instalado, listo para el siguiente usuario.

Ferias y exposiciones donde diversos participantes muestran software a potencialesclientes pueden realizar demostraciones como siempre. Una vez se quiera volvera acondicionar el equipo para nuevas demostraciones basta con reiniciar el equipo

1Un programa espıa o spyware es una aplicacion que recopila informacion sobre una persona u organi-zacion sin su conocimiento.

2Un programa adware es cualquier programa que automaticamente ejecuta, muestra o baja publicidadal computador despues de instalado el programa o mientras se esta utilizando la aplicacion.

3Malicious software o software malicioso es un software que tiene como objetivo infiltrarse en o danarun ordenador sin el conocimiento de su dueno y con finalidades muy diversas.

2

1.2 Estado del arte

y este volvera a su estado original. Incluso se puede dejar al cliente que pruebe elsoftware con la certeza de que sera muy simple restaurar el equipo.

El caso de maquinas de practicas para alumnos serıa bastante similar al anterior. In-cluso se podrıa permitir la instalacion de software por parte del alumno, ya que unavez que este termine de usar el equipo, el sistema quedarıa listo para volver a usar-se. Este caso es bastante parecido al de empresas que dan soporte y mantenimientode equipos desplegados en las instalaciones de otras empresas.

1.2. Estado del arteUna vez aclarados los posibles usos y beneficios del TFC, parece necesario describir

las soluciones encontradas y en uso actualmente, ya sean software o hardware, y mostrarsus beneficios y sus inconvenientes. Se comenzara con aquellos productos mas genericoso cuyo uso principal no se corresponda con las situaciones anteriormente expuestas y seterminara por las mejores soluciones encontradas, siendo la ultima una solucion hardware.

1.2.1. Software de clonado de disco

Figura 1.1: Norton Ghost 14.0.

Este tipo de software es utilizado para clonar discos duros. La copia puede ser sec-tor a sector, de forma que se clone completamente la particion, sin variar su tamano, o

3


transfiriendo el contenido del sistema de ficheros a otro sistema de ficheros en otro disco,incluso de tamano distinto. Esta ultima caracterıstica requiere de un software capaz detrabajar con los sistemas de ficheros mas comunes como son FAT, NTFS, Ext2 y Ext3. Elsoporte clonado puede ser transferido a otro disco, en la misma maquina o vıa red, ademasde almacenarse en otro dispositivo para un uso posterior. Algunos software permiten in-cluso editar esa imagen y ası modificar los ficheros o directorios contenidos.

Norton Ghost (ver figura 1.1) es el software de este tipo mas conocido y fue el pri-mero en abrir mercado para el software de clonado de disco. Hay mas productos de otrosfabricantes, como PartImage y Paragon Drive Backup, para los sistemas operativos masusados.

A favor:

• Permite restaurar el soporte a partir de una imagen limpia comodamente, so-brescribiendo datos y metadatos4.

• A veces se puede planificar la restauracion para que se realice en un momentodeterminado. Ese momento puede ser en una hora determinada o cuando elusuario cierre la sesion.

• Este tipo de software suele tener un modo de funcionamiento autonomo conel cual es posible restaurar una imagen sin el apoyo de un sistema operativo.

En contra:

• Cada vez que se realizan modificaciones al soporte que es necesario salva-guardar hay que actualizar la imagen.

• El tiempo de espera para restaurar una imagen depende de si siempre restaurala imagen sin importar lo que se haya modificado, o de si tiene en cuenta losficheros y directorios modificados para restaurar unicamente estos.

1.2.2. Restaurar sistema en Windows XPRestaurar sistema (ver figura 1.2) es un componente de Windows Me, Windows XP y

Windows Vista que permite al equipo volver a un estado anterior. Esa vuelta atras se con-sigue mediante la restauracion de los ficheros, programas instalados, claves de registro,etc. que hubiera en el momento en el que se realizo la instantanea del equipo o punto derestauracion.

Para que los puntos de restauracion no ocupen el soporte completamente, se limitael espacio disponible para los mismos hasta el 13 % del total del soporte. Si ese espacioquedara ocupado completamente, el sistema irıa eliminando automaticamente los puntosde restauracion mas viejos.

4Los metadatos son, literalmente, “datos acerca de los datos” y aportan informacion o ayudan a ubicardatos.

4

1.2 Estado del arte

Figura 1.2: Restaurar sistema en Windows XP.

A favor:

• Su integracion con el sistema operativo hace que sea muy facil de usar.

• Guarda puntos de restauracion automaticamente ante cambios crıticos en elsistema operativo, como son las actualizaciones mediante Windows Update5,la instalacion de nuevo software o de controladores no firmados digitalmente,cada cierto tiempo de uso, etc. ademas de “a peticion del usuario”.

En contra:

• Esta solucion solo funciona en las plataformas Windows antes indicadas.

• En Windows XP depende del sistema operativo, de forma que si este es inca-paz de arrancar no se podra restaurar el sistema.

• Si no hay espacio libre no se crean los puntos de restauracion automaticos,y sera posible el caso de que un usuario descubra que no puede restaurar elsistema porque no se ha podido crear ningun punto de restauracion.

5Es un servicio que da Microsoft a sus usuarios de Windows. Permite aplicar parches de seguridad alsistema operativo y a sus productos de forma automatica.

5


• No protege ıntegramente el volumen, sino aquellos ficheros y directorios per-tenecientes al perfil6 de los usuarios, ademas de contenido crıtico del sistema.

1.2.3. Maquina virtual de sistema con instantaneas de estado

Figura 1.3: Gestion de instantaneas en VMware Workstation.

El software de virtualizacion multiplexa el acceso al hardware de forma que distintasmaquinas virtuales pueden disponer de el como si fueran las unicas con acceso al mis-mo. El hardware virtualizado es mostrado al usuario como una maquina virtual capaz deejecutar aplicaciones o sistemas operativos como si fuese la maquina real. Normalmentehay cierta penalizacion en el rendimiento, pues solo hay un hardware (entiendase comoun conjunto de piezas hardware que constituyen el equipo) y debe planificarse el accesode varias maquinas a un mismo recurso. Algunos fabricantes de procesadores como Intelo AMD han anadido extensiones a sus procesadores para ası facilitar el trabajo con estetipo de software y aumentar el rendimiento.

El fabricante por excelencia es VMware7 con su software VMware Workstation (verfigura 1.3), aunque hay mas soluciones de otros fabricantes como Parallels Workstation o

6Es un conjunto de ficheros y directorios que almacenan documentos y ajustes del sistema para eseusuario en particular.

7http://www.vmware.com/

6

1.2 Estado del arte

QEMU8.El usuario puede crear maquinas virtuales con las que trabajar y, antes de realizar

algun cambio crıtico en alguno de los soportes, tomar una “foto” o instantanea de lamaquina. Si necesitase volver a un punto anterior, bastarıa con restaurar la maquina vir-tual partiendo de la instantanea. Se pueden realizar varias instantaneas e incluso volver aalguna de ellas y crear otra mas sin sobrescribir las posteriores de forma que, mas que unasecuencia lineal de estados de la maquina, se obtenga un arbol de estados, cada uno convariaciones sobre la maquina virtual original.

A favor:

• Facilidad para crear y gestionar las instantaneas ademas de poder guardar tan-tas como se deseen.

• Al poder guardar el estado completo de la maquina, se puede volver no solo alestado original del dispositivo que sufrio la modificacion que se quiere desha-cer, sino al mismo instante de la operacion, restaurando ademas las aplicacio-nes que estuvieran funcionando con los datos que manejaran en ese momento.

• Se pueden eliminar las instantaneas intermedias si se desea mantener los cam-bios.

En contra:

• El rendimiento se ve penalizado con respecto al hardware real.

• Estas maquinas no pueden virtualizar todo tipo de hardware por ello, si elsoftware de virtualizacion no da soporte para un hardware especıfico, este noestara disponible dentro de la maquina.

1.2.4. “Instantaneas” y “clones” en ZFSZFS es un sistema de ficheros disenado por Sun Microsystems9 para su sistema opera-

tivo Solaris. El significado de las iniciales proviene del ingles Zettabyte File System. Pu-blicado a finales del 2005, fue desarrollado para utilizarse en sistemas de almacenamientode alta capacidad. Posee ciertas caracterısticas singulares como son la comprobacion yreparacion de datos al vuelo y la posibilidad de guardar instantaneas y clones de cadafichero.

Una instantanea es una copia de solo lectura de un fichero situado en un volumenZFS. Se crea al momento e, inicialmente, no consume espacio adicional. A medida que elfichero original cambie, la instantanea ira ocupando espacio para poder hacer referenciaal contenido original. Cuando se quiera recuperar el contenido del fichero, tal y comofue capturado por la instantanea, bastara con indicar al sistema de ficheros que revierta elestado del fichero usando la informacion de la instantanea.

8QEMU es un emulador de procesadores basado en la traduccion dinamica de binarios (conversion delcodigo binario de la arquitectura fuente en codigo entendible por la arquitectura huesped).

9http://www.sun.com/

7


Un clon es una instantanea que puede ser modificada, de forma que los cambios de-sarrollados en el clon pueden ser trasladados, una vez se este seguro de su contenido, alfichero original del que se partio.

A favor:

• Permite tener multiples instantaneas de un mismo fichero y es posible regresara cada una de ellas.

• Las copias pueden ser modificadas y, dependiendo del resultado, volver alfichero capturado en la instantanea o sobrescribirlo con la copia modificada.

En contra:

• Al generar una instantanea de un fichero, es probable que se produzca ciertafragmentacion. Si la fragmentacion aumentase, por ejemplo, al realizar variasinstantaneas de un mismo fichero, podrıa verse perjudicado el rendimiento.

• El usuario tiene que haber tomado una instantanea antes de proceder a realizaralgun cambio crıtico. Ante cambios inesperados, como un virus o un borradoaccidental, el usuario se encuentra desamparado.

• Al ser una caracterıstica de ZFS, solo podra ser utilizada en aquellos siste-mas operativos donde, ademas de encontrarse implementado este sistema deficheros, se haya implementado tambien esta avanzada caracterıstica.

1.2.5. BranchFS en SkyOSSkyOS10 es un sistema operativo con interfaz grafica, en constante desarrollo, escrito

para la arquitectura IA-32. Nacio como un experimento en el desarrollo de sistemas ope-rativos por parte de su autor, Robert Szeleney, mientras estudiaba en la universidad. Entresus caracterısticas principales cabe destacar:

Multitarea apropiativa ademas de caracterısticas basicas como proteccion de proce-sos e hilos y gestion de memoria virtual.

Soporte para VESA desde el nucleo, permitiendo una interfaz grafica nada masiniciarse el SO.

Soporte para SMP11 e Hyper-threading12.

Sistema de ficheros propio, SkyFS, derivado de OpenBFS.

10http://www.skyos.org/11Multiprocesamiento simetrico, del ingles Symmetric MultiProcessing, es una arquitectura de compu-

tadores donde dos o mas procesadores identicos se hallan conectados a la misma memoria principal.12Es una tecnologıa propietaria de Intel utilizada para mejorar la paralelizacion de los calculos que se

realizan en un PC mediante la ejecucion de multiples hilos independientes.

8

1.2 Estado del arte

Ademas, dispone de un sistema de ficheros virtual denominado BranchFS capaz decrear una “rama13” de un sistema de ficheros cualquiera. Al trabajar sobre esta rama, setiene acceso al sistema de ficheros del que se partio, pero cualquier cambio que se realiceno afectara al original. Al crear la rama, debe indicarse el soporte que almacenara loscambios del sistema de ficheros.

A favor:

• Al ser virtual, se pueden crear ramas del sistema de ficheros de un DVD deforma que, aparentemente, se pueda escribir sobre el mismo.

• Permite utilizar, como soporte donde guardar los cambios, un disco de memo-ria, ası las operaciones sobre los ficheros modificados seran mas rapidas.

• Los cambios permanecen entre reinicios si el soporte es persistente y no seborra su contenido.

En contra:

• Se puede encontrar exclusivamente en SkyOS.

• Las modificaciones no se pueden combinar con el sistema original si interesaraconservarlas.

• A peticion del usuario se crean las ramas. Si hay algun cambio inesperado quealtere el sistema y no se esta trabajando en un rama, no se podran deshacer loscambios.

1.2.6. Software de proteccionHDGUARD14 (ver figura 1.4) es un software para Windows cuya objetivo es proteger

el contenido de las unidades especificadas. Todas las modificaciones realizadas en las mis-mas son desviadas a una particion no utilizada o a un fichero propio. Estas modificacionesperduraran hasta que el usuario decida eliminarlas, o podran ser aceptadas e integradascon el resto de datos del soporte.

Otro ejemplo de este tipo de software es DeepFreeze15 de Faranoics.

A favor:

• Puede mantener los cambios entre reinicios tanto tiempo como sea necesario.

• Si se desea, los cambios pueden ser aplicados a los soportes protegidos.

• Los cambios pueden ser almacenados en una particion no usada o en un ficherode intercambio.

13Entiendase “rama” como una copia que deriva de un original al que se halla ligado.14http://www.hdguard.com/15http://www.deepfreeze.com/

9


Figura 1.4: HDGUARD en Windows XP.

En contra:

• No puede guardar diferentes estados o puntos de restauracion.

• Si se quiere deshacer los cambios de una unidad, aunque no sea la de sistema,es necesario reiniciar el equipo.

1.2.7. Hardware de proteccionExisten soluciones hardware equivalentes a las soluciones software expuestas en el

apartado anterior. Un ejemplo de ellas son las tarjetas WinSchool Safety Card (ver figura1.5) o Hard Drive Recovery Card.

A favor:

• Puede proteger incluso la configuracion de la BIOS16.

• Puede mantener los cambios entre reinicios.

• Los soportes protegidos pueden ser actualizados con los cambios.

• Amplio soporte de sistemas operativos.

En contra:

• No puede guardar diferentes estados o puntos de restauracion.

16BIOS, del ingles Basic Input/Output System, es un microcodigo que se encarga de identificar e inicia-lizar los componentes hardware del equipo. De esta forma prepara el equipo para que otro software puedatomar el control del mismo.

10

1.3 Objetivos

• Si se quiere deshacer los cambios de una unidad, aunque no sea la de sistema,es necesario reiniciar el equipo.

• Salvo por la proteccion de la BIOS, no ofrece ningun beneficio adicional porser una pieza hardware.

Figura 1.5: Tarjeta PCI WinSchool Safety Card.

1.3. ObjetivosEl objetivo del TFC es desarrollar una solucion para los problemas dados en la intro-

duccion, pero siempre pensando que su sistema operativo destino es Linux. La eleccionde Linux viene dada porque esta disponible su codigo fuente y se puede modificar a vo-luntad para anadirle todas aquellas capacidades nuevas que se deseen. Cierto es que sepodrıa desarrollar una solucion para Windows mediante el API17, ofrecida por el DDK18

de Microsoft, pero, como se ha indicado en el punto anterior, ya hay varias solucionespara esa plataforma.

El funcionamiento deseado es el siguiente: dada una particion cualquiera formateadacon cierto sistema de ficheros (a partir de ahora, SF) y lista para usar, cualquier accesode escritura a esta particion no modificara realmente la misma, aunque sı debera reflejaresos cambios como si se hubieran producido. En cambio, la lectura de datos de esa par-ticion debera devolver los datos que se hallaran en ella o, si hipoteticamente se hubieranmodificado, los datos actualizados. La escrituras deben, por tanto, redirigirse a los huecoslibres de la particion sin sobrescribir datos y/o metadatos o escribirlos directamente enotro soporte.

No es aceptable dejar las escrituras simplemente en memoria, sin respaldo en otrosoporte, por el gran consumo de memoria del espacio del nucleo que podrıa llegar a pro-ducirse.

17Un API (del ingles Application Programming Interface - Interfaz de Programacion de Aplicaciones) esel conjunto de funciones y procedimientos (o metodos si se refiere a programacion orientada a objetos) queofrece cierta biblioteca para ser utilizado por otro software como una capa de abstraccion.

18Un DDK (del ingles Driver Development Kit - Kit de Desarrollo de Controladores) es un conjunto deherramientas que permite el desarrollo de controladores de dispositivo para una cierta plataforma.

11


El resultado final esperado es que, aun habiendo escrito, modificado y/o borrado datosde la particion, esta, una vez se decida deshacer los cambios, vuelva al estado que tenıaal empezar a trabajar con ella. Concretamente, desde el punto de vista del usuario, esteno notara modificacion alguna en los datos; desde el punto de vista del SF, ademas, losmetadatos estaran intactos. Es decir, se puede restaurar la particion al punto en el quese hallaba al empezar a trabajar con ella, obviando datos posiblemente escritos por lasolucion en aquellas zonas no usadas (que no ignoradas) por el SF.

Notese que, aunque esto se asemeje a una especie de puntos de guardado de la parti-cion, solo se podra retornar al punto inicial. No habra puntos intermedios: todo o nada.Lo de “todo” viene porque, como objetivo opcional, se propone la posibilidad de “sin-cronizar” la particion con los datos que deberıan haberse escrito. Este proceso de sincro-nizacion debera tomar los datos que el SF da por escritos en la particion y escribirlosrealmente en aquellas posiciones que el SF indico en su momento.

Ademas, los cambios se desharan automaticamente si se reinicia el equipo. Realmenteno se deshara nada, ya que, al reiniciar y volver a montar la particion, los cambios noapareceran, porque nunca fueron fusionados con el resto de datos y metadatos del SF dela particion.

Idealmente, la solucion no deberıa estar atada a ningun sistema de ficheros en particu-lar, pero, si esto no fuera posible, se dara prioridad a aquella solucion que permita el usode los SF mas comunes como son Extended 2, Extended 3 y ReiserFS.

Tambien es necesario que no requiera de hardware adicional, es decir, que la solucionsea eminentemente software y funcione en un equipo normal.

Parece obvio pensar que una solucion que de respuesta a todas estas premisas debesepararse en dos partes:

1. Un controlador o driver que se encargue de tratar las operaciones de acceso a laparticion. La necesidad del controlador surge para poder acceder directamente aldispositivo de bloques que se protege y ası controlar lo que el SF le envıe.

2. Una aplicacion que se encargue de hacer llegar al controlador las necesidades delusuario. Es decir, que particion se quiere proteger, si se quiere deshacer las escritu-ras, etc.

Otro objetivo opcional sera conseguir que la solucion funcione con la particion quese usara como directorio raız, es decir, el primer directorio de la jerarquıa de directoriosdel sistema. Se marca como objetivo porque, al contrario que otras particiones, esta semonta la primera y suele tener mas restricciones de uso. El problema es el siguiente: laaplicacion de control se encuentra en la particion raız que se quiere proteger. Si se montala particion para acceder a la herramienta, ya no se podra desmontar esa particion. Si nose puede desmontar, ¿como puede ser protegida? Si no se monta, ¿como se accede a laherramienta? ¿Como podrıa resolverse este cırculo vicioso? La solucion a este problemasera un objetivo secundario.

Es necesario comentar que, aunque se hable constantemente de una particion, esto notiene por que ser ası. Es decir, la solucion se centrara en los dispositivos de bloques, yasea la propia particion, un disco entero formateado para su uso, o un fichero simulandoser un dispositivo de bloques por medio del dispositivo loop.

12

1.4 Estructura del libro

Dependiendo de la solucion que se desarrolle, es posible que se anadan nuevos obje-tivos adicionales. Estos objetivos deberan indicarse cuando se explique detalladamente lasolucion elegida finalmente de entre varias propuestas. Esta discusion se desarrollara enel capıtulo 2.

Por motivos de seguridad, la solucion solo podra ser gestionada por el usuario root19.Ademas, la solucion sera inutil ante cambios directos a la particion (dispositivo /dev/xxxcorrespondiente) o ante cambios realizados fuera del sistema como son desde Windows uotras versiones de Linux sin la solucion habilitada, por ejemplo, un LiveCD20.

Finalmente, la solucion final sera publicada bajo licencia GPL21 y exclusivamente laversion 2.

1.4. Estructura del libroEl libro esta estructurado por capıtulos y de la siguiente forma:

Introduccion y objetivos: es el capıtulo actual. Trata, como se ha visto, de las moti-vaciones del proyecto. Ademas, se ha detallado una lista de soluciones encontradaspara poder definir con conocimiento de causa que es lo que se quiere obtener. Final-mente, se ha propuesto una serie de objetivos que debera cumplir al final la soluciondesarrollada.

Planteamiento de soluciones: enumerara distintas propuestas realizadas, con sus pros ysus contras, y con un cierto nivel de detalle para elegir finalmente la mejor de ellas.

Conceptos preliminares: describira y explicara conceptos basicos del nucleo Linux, so-bre todo aquellos que han sido utilizados en el desarrollo de la solucion.

Desarrollo e implementacion de la solucion: mostrara con sumo detalle la solucion es-cogida y todo el desarrollo realizado hasta su conclusion. A veces se hablara deciertos subsistemas o componentes de Linux que han sido investigados y utilizados,como por ejemplo la gestion de dispositivos de bloques. Tambien se explicara lalogica implementada para poder atender las peticiones de E/S, ademas de los pro-blemas encontrados, como son los accesos concurrentes a estructuras.

Caracterısticas opcionales: es el capıtulo encargado de explicar aquellos objetivos op-cionales desarrollados, como, por ejemplo, la optimizacion en el consumo de me-moria o la integracion de la solucion con el sistema de compilacion de Linux.

19En sistemas operativos del tipo Unix, root o superusuario es el nombre convencional de la cuenta deusuario que posee todos los derechos en todos los modos (mono o multi usuario).

20Sistema operativo (normalmente acompanado de un conjunto de aplicaciones) almacenado en un medioextraıble, tradicionalmente un CD o un DVD, que puede ejecutarse desde este sin necesidad de instalarloen el disco duro de un ordenador, para lo cual usa la memoria RAM como disco duro virtual y el propiomedio como sistema de ficheros.

21Es una licencia creada por la Free Software Foundation a mediados de los 80 y esta orientada princi-palmente a proteger la libre distribucion, modificacion y uso de software.

13


Conclusiones y futuras lıneas: aquı se intentara determinar los beneficios de la soluciony si cumple con todos los objetivos propuestos o, en el caso de que no fuera ası,por que ha sucedido. Ademas se dara una breve valoracion personal del trabajodesarrollado y un breve vistazo a posibles lıneas futuras.

Apendices: los dos apendices aportaran informacion sobre otras actividades relacionadascon el proyecto, aunque no directamente. Ası, se informara de como debe compilar-se y usarse el proyecto, de las herramientas utilizadas y de las pruebas desarrolladas.

14

Capıtulo 2

PLANTEAMIENTO DESOLUCIONES

2.1. IntroduccionComo se puede apreciar en la figura 2.1, Linux esta estratificado en varias capas y al-

gunos de sus sistemas no solo prestan servicios a las aplicaciones del usuario sino tambiena otros sistemas del nucleo.

Figura 2.1: Diagrama de sistemas de Linux.

En el ejemplo, se observa como se ofrecen al usuario el sistema de memoria virtual (eningles, Virtual Memory Manager o VMM) y el sistema de ficheros (en ingles, Virtual FileSystem o VFS). VFS es una capa de abstraccion situada encima de los verdaderos sistemasde ficheros: Ext2, Ext3, ReiserFS, etc. Su mision consiste en proporcionar acceso, demanera uniforme, a los distintos sistemas de ficheros a los que el SO da soporte.

Por otro lado, VMM se encarga de la gestion de la memoria y de ofrecerla a lasaplicaciones y a los distintos sistemas del nucleo. Ese es el motivo por el que los sistemasde ficheros aparecen representados encima de la capa VMM.

15

PLANTEAMIENTO DE SOLUCIONES

Debajo de VMM se halla la capa de E/S de bloques (en ingles, Block I/O Layer oBIO), cuya mision es proporcionar acceso a los dispositivos del sistema, como puedenser discos duros, disquetes y demas dispositivos de bloques. VMM hace uso de esa capa,ya que mucha de la informacion que se almacena en memoria proviene de los soportesmencionados anteriormente, en su mayorıa imagenes ejecutables, bibliotecas o ficherosde datos.

Finalmente, BIO se encarga de acceder a los dispositivos mediantes los controladoresadecuados, que son quienes, en ultima instancia, tratan con el hardware.

Por ejemplo, para una lectura de un fichero, la peticion se traslada mediante llamadasal sistema hasta VFS. Este averigua en que tipo de sistema de ficheros se halla y procedea trasladar la peticion al SF adecuado. El SF localiza en que disco y en que sector seencuentra el fichero y procede a leerlo del soporte. Para ello, reserva unas paginas dememoria mediante VMM. A continuacion, envıa una peticion a BIO para que proceda aleer del disco dado y en el sector indicado los bloques que necesite. Esos bloques seranleıdos del soporte utilizando el controlador correspondiente a ese disco, y su contenidoalmacenado en la memoria previamente solicitada. Esta memoria sera proporcionada a laaplicacion que solicito los datos para que los utilice convenientemente.

En los apartados siguientes se explicaran las propuestas acompanadas de sus bene-ficios y sus inconvenientes. Tomando la figura de partida, se resaltaran aquellas capasmodificadas o, si fuera necesario, aquellos elementos anadidos para conseguir alcanzar lasolucion.

2.2. Propuestas

2.2.1. Modificacion de un sistema de ficheros

Como solucion mas inmediata se propone la modificacion de un sistema de ficherosde uso mayoritario como, por ejemplo, Extended 2. Extended 2 (tambien conocido comoExt2) es un sistema de ficheros para Linux desarrollado por Remy Card como reemplazode Extended. Al contrario que su sucesor, Extended 3, no posee capacidades de journa-ling1. Tolera particiones de hasta 16 TiB, con un tamano maximo de fichero de 2 TiB yhasta 1018 archivos.

Ext2 divide el espacio de la particion en bloques del mismo tamano, agrupando cadabloque varios sectores. Los bloques son, a su vez, asociados en grupos para ası intentarreducir la fragmentacion de los ficheros, ya que Ext2 intenta que los datos de un ficheroesten siempre en el mismo grupo. La figura 2.2 ofrece una vista de la estructura del sistemade ficheros Ext2 en un disco.

Dentro de cada grupo hay:

Un superbloque: se encarga de almacenar cierta informacion, como puede ser el ta-mano del bloque, el numero total de bloques, el numero de bloques libres, el numero

1Es un mecanismo por el cual un sistema informatico puede implementar transacciones. Tambien se leconoce como registro por diario.

16

2.2 Propuestas

Figura 2.2: Estructura de una particion Ext2 y de su grupo de bloques.

de bloques por grupo, el numero de veces que se ha montado la particion, el esta-do de la misma, etc. Ext2 solo usa la informacion contenida en el superbloque delprimer grupo (superbloque 0); el resto de superbloques de los demas grupos suelenser replicas del superbloque 0 y son utilizados si este ultimo no es consistente.

Descriptores de grupo: indican en que posicion del soporte se encuentran el mapade bits de i-nodos, el mapa de bits de bloques de datos y la tabla de i-nodos decada grupo. Todos estos datos de cada grupo se hallan contenidos en descriptoresde grupo y ademas todos ellos estan replicados en los distintos grupos. Al igual quecon el superbloque, solo se usa el del primer grupo; el resto se utiliza si se detectanproblemas de consistencia.

Mapa de bits2 de bloques de datos: indica que bloques de datos estan disponibles ycuales no.

Mapa de bits de los i-nodos: indica que i-nodos estan disponibles y cuales no.

Tabla de i-nodos: almacena los i-nodos, cada uno de los cuales se utiliza para des-cribir un fichero o directorio. Guarda datos tales como el propietario, los permisos,el tamano y, lo mas importante, punteros a los bloques de datos que conforman elcontenido del fichero o directorio.

Bloques de datos: almacenan el contenido de los ficheros y directorios.

Conocida su estructura logica en el soporte, es necesario enumerar algunas de suscaracterısticas:

Tamano de bloque variable entre 1024, 2048 y 4096 bytes. El bloque es la unidadmınima de transferencia y suele agrupar varios sectores. Un tamano de bloque pe-queno es ideal para ficheros de pocos bytes, puesto que ası se desperdicia menos

2Un mapa de bits es una estructura que utiliza cada bit para indicar el estado de cada objeto en unacoleccion de ellos. En este caso, indica si esta en uso o no el bloque o i-nodo indicado.

17


espacio libre por cada bloque no ocupado completamente. Por el contrario, paraficheros grandes es mejor un tamano de bloque grande tambien, de forma que setransfieran menos bloques entre el soporte y la memoria.

Preasignacion de bloques de datos. Se asigna previamente espacio contiguo a losficheros, es decir, bloques fısicamente adyacentes a los datos ya escritos. Ası, cuan-do el tamano del fichero crezca, se podran usar esos bloques y paliar los clasicosproblemas de fragmentacion que suelen reducir el rendimiento del sistema.

Admite ficheros inmutables (no pueden ser modificados, borrados o renombrados),ficheros a los que solo se les puede anadir mas datos y enlaces simbolicos.

Detecta si no se desmonto correctamente la particion la ultima vez que se utilizo,forzando un chequeo de comprobacion de la misma si fuera necesario.

Figura 2.3: Modificacion propuesta: Ext2.

A partir de la estructura del sistema de ficheros Ext2 es facil aventurar el contenido dela propuesta:

1. Todo bloque que se modifique y se quiera escribir en la particion, ya sea el super-bloque, un mapa de bits o un bloque de datos de un fichero debe escribirse en unbloque de datos libre, donde no sobrescriba informacion de ningun tipo.

2. Las lecturas se trataran como siempre ha hecho el sistema de ficheros, con la salve-dad de que toda aquella peticion de lectura que tenga que ver con bloques reubica-dos debera redirigirse a los bloques utilizados en el paso anterior.

3. Nuevas escrituras sobre datos ya reubicados deberan usar los mismos bloques quese utilizaron anteriormente.

18

2.2 Propuestas

Se usara la palabra “reubicar” para indicar el procedimiento de redirigir los accesosde escritura a la particion y tambien a los accesos de lectura de bloques almacenadostemporalmente, es decir, aquellos que seran desechados cuando se quiera restaurar elestado original de la particion.

Esta propuesta sera denominada como Ext2rb. El sufijo rb viene dado por el terminorollback y, aunque no sea realmente un sistema con soporte para varias “vueltas atras”,sı tiene que ver con el proposito del TFC: deshacer los cambios al terminar de trabajarcon el soporte.

Las nuevas labores de esta modificacion de Ext2 seran las siguientes:

1. Localizar aquellos bloques de datos libres que se puedan usar para almacenar datosmodificados o nuevos.

2. Analizar cada peticion de lectura o escritura y tratarla adecuadamente:

a) Si es una lectura:

1) Si no se realiza sobre datos modificados, devolver los bloques pedidos oacceder a los metadatos correspondientes.

2) Si se realiza sobre datos modificados previamente, redirigir la peticion alos bloques donde realmente esta la informacion.

b) Si es una escritura:

1) Si es la primera vez que se escribe en esos bloques, utilizar un bloquelibre.

2) Si ya se ha reubicado previamente, seguir usando esos mismos bloques.

Como pequena optimizacion, todos aquellos bloques libres que se asignen a nuevasescrituras no necesitaran ser reubicados pues ya estan usando un bloque libre. Por contra,los metadatos, ası como los mapas de bits, sı deberan escribirse en algun bloque libre oen uno reubicado previamente, pero siempre sin sobrescribir los originales.

Una ventaja adicional es que al utilizar solo los bloques libres, el verdadero Ext2podra seguir usando la particion cuando se quiera trabajar con ella a la manera tradicional.No es necesaria conversion ni modificacion alguna de la estructura logica en el soporte.

La desventaja evidente es que esta solucion es muy particular y solo serıa valida conparticiones que usen Ext2 y, dependiendo del grado de compatibilidad, Ext3. Pero el ver-dadero problema no es este sino como se encuentra implementado Ext2 dentro del codigode Linux.

Toda la gestion de acceso a bloques del sistema de ficheros esta ıntimamente ligadaal sistema de memoria virtual. Por ejemplo, ante una peticion de lectura, se procede a lalectura de los bloques pedidos desde el soporte y se almacenan en memoria, dentro depaginas de memoria. Si se modificaran esos bloques, Ext2 no serıa consciente de ello, niningun subsistema de Linux le avisarıa y, por tanto, no procederıa a actualizar el contenidodel soporte. Pero, a pesar de ello, el contenido de los bloques serıa sincronizado con el delsoporte. ¿Como es esto posible? La respuesta hay que buscarla en el sistema de memoriavirtual ya que, desde el momento que pasan a estar en paginas de memoria esos bloques,

19


es este sistema el encargado de actualizar el contenido del soporte si se hiciera algunamodificacion a esos bloques.

Por tanto, esta solucion no serıa correcta o, al menos, no tal y como se ha descrito.Para que funcionase habrıa que modificar el sistema de memoria virtual segun se explicaen el siguiente apartado.

Otro problema es que depende de los bloques libres que existan en el momento deempezar a trabajar con la particion. Si apenas queda espacio libre, solo se permitiran unaspocas modificaciones hasta agotar el deposito de bloques libres.

2.2.2. Adaptar el sistema de memoria virtualPara evitar los problemas de la solucion anterior se propone realizar unas modifica-

ciones al sistema de memoria virtual. Este sistema, junto con la MMU3, se encarga depermitir al software que utilice mas memoria de la que realmente posee el ordenador.Concretamente, en la arquitectura IA-32, el lımite son 4 GiB (232); para IA-32 con PAE4,el lımite son 64 GiB (236); en AMD64, aunque el lımite teorico es de 16 EiB5 (264), lasimplementaciones actuales solo alcanzan a manejar 256 TiB6 (248).

Figura 2.4: Modificacion propuesta: Ext2 y el sistema de memoria virtual.

Este sistema divide el espacio de memoria en porciones denominadas marcos de pagi-na con un tamano, en IA-32, de 4 KiB7. Estos marcos se gestionan mediante una estructu-ra conocida como tabla de paginas. La tabla es una estructura multinivel que asocia cadadireccion de memoria virtual con un marco de pagina fısico.

3La unidad de manejo de memoria o Memory Management Unit es la responsable de manejar los accesosa la memoria. Ademas, se encarga de traducir direcciones virtuales a direcciones fısicas, de comprobar lospermisos de acceso, del control de la cache, etc.

4Extension de direcciones fısicas o Physical Address Extension habilita mas lıneas en el bus de direc-ciones del procesador pudiendo usar direcciones de 36 bits.

5Exbibyte (260 bytes).6Tebibyte (240 bytes).7En AMD64, el tamano de pagina es de 8 KiB.

20

2.2 Propuestas

El proceso de traduccion para IA-32, que se puede observar en la figura 2.5, es elsiguiente:

Figura 2.5: Traduccion de una direccion de memoria virtual a una direccion fısica.

1. Dada una direccion de memoria virtual, se toman los 10 bits (posiciones 31 a la 22,ambas inclusive) mas significativos y se indexa con ellos en la tabla de directoriosindicada por el ındice de directorios. El resultado de indexar es una direccion dememoria donde se halla una tabla de paginas.

2. Esta ultima tabla es indexada con los siguientes 10 bits (posiciones 21 a 12, ambasinclusive) mas significativos de la direccion dada. El resultado, una vez mas, es unadireccion de memoria donde se halla el marco de pagina correspondiente y, portanto, la pagina.

3. El desplazamiento dentro de esa pagina viene dado por los 12 bits restantes y senalala posicion real en memoria donde se encuentra el dato solicitado.

El directorio de paginas contiene referencias a tablas de paginas. Las tablas de paginascontienen referencias a los marcos de pagina que, a su vez, contienen las paginas dememoria.

Como se explico en el apartado anterior, los bloques se almacenan en paginas de 4KiB. Por tanto, el tamano de bloque de los sistemas de ficheros debe cumplir dos condi-ciones:

21


1. Debe ser multiplo de dos y menor o igual que el tamano de pagina: 4096 bytes o 4KiB.

2. Debe ser multiplo de 512, que es el tamano estandar en bytes de un sector.

Por estas condiciones es por las que en IA-32 solo se daran por validos los siguientestamanos: 512, 1024, 2048 y 4096 bytes.

Todo bloque leıdo, y por tanto almacenado en una pagina, ya sea ocupandola entera oen parte, tiene ademas una estructura asignada que se denomina buffer head. Esta estruc-tura indica de que soporte se obtuvo el bloque y de que sector. Cuando se modifique esebloque, y el sistema de memoria virtual lo considere adecuado, se sincronizara el conteni-do del bloque en la pagina con el soporte, escribiendo la pagina en el dispositivo y sectorindicados. Obviamente, el tamano de la escritura es el tamano del bloque, el cual no varıapara esa particion.

Figura 2.6: Relacion entre los bloques, las paginas, el soporte y los buffer head.

La figura 2.6 representa una pagina de 4 KiB con cuatro bloques de 1 KiB leıdosdel disco. Cada bloque tiene asociado una estructura buffer head que es la encargada demantener el vınculo entre los datos en memoria y su ubicacion en el disco.

Los cambios necesarios para esta propuesta (ver figura 2.4) serıan los siguientes:

Cuando se proceda a sincronizar bloques (o nuevos bloques) con el soporte prote-gido8, se sustituira dentro de la estructura buffer head el valor que indica el sectorpor otro que evite que se sobrescriban datos en el soporte.

El sistema de ficheros Ext2rb debera elaborar una lista de los bloques libres que elsistema de memoria virtual pueda utilizar para escribir aquellos bloques que nece-site en el soporte.

8Protegido significa que no se quiere alterar realmente el contenido del soporte.

22

2.2 Propuestas

Una desventaja es que se obtiene un sistema que no sera portable, ya que modifica elcodigo interno del nucleo que no tiene por que mantenerse estable entre distintas versio-nes del mismo, ni podra ser distribuido como modulo al modificar un sistema del nucleo.Ademas, es un sistema crıtico y bastante complejo, del que dependen muchos otros sis-temas y en el que las modificaciones, si no se testean exhaustivamente, pueden dar lugara corrupciones en todos los dispositivos del sistema. Requiere modificaciones demasiadoambiciosas para lo que se quiere obtener.

Esta propuesta, aunque completa la anterior, sigue sin ser suficientemente generica,pues solo se podrıa aplicar a Ext2. Para que funcionase con otros sistemas de ficherosdeberıan estudiarse su estructura y funcionamiento a fin de poder deducir donde habrıabloques libres que utilizar.

2.2.3. Intercepcion de la capa de E/S de bloquesSiguiendo con el sistema de ficheros Ext2 pero sin tener que modificar un sistema

tan complejo como es el de memoria virtual, se propone modificar la capa encargada deescribir los bloques al disco (ver figura 2.7).

Figura 2.7: Modificacion propuesta: Ext2 y la etapa de E/S.

Despues de que el sistema de memoria decida sincronizar ciertas paginas con susbloques correspondientes en disco, se genera una estructura con la informacion necesariapara llevar a cabo esa operacion que es enviada a la capa de E/S de bloques, para queescriba realmente los cambios en el dispositivo de bloques adecuado. Modificando estaetapa, se podrıan obtener los mismos resultados que con la propuesta combinada anterior,pero sin apenas modificar el codigo de Ext2 y afectando levemente a un sistema crıticodel nucleo.

Mas detalladamente, el contenido de la propuesta es el siguiente:

1. Al montarse un soporte con Ext2, este debera indicar, por ejemplo mediante lasopciones de montaje, otro soporte que almacenara las escrituras que sera denomi-

23


nado DE (dispositivo de escrituras). El soporte Ext2, del que solo se realizaran lec-turas, sera denominado DL (dispositivo de lecturas). Evidentemente, DE tambientendra lecturas de los datos escritos en el.

2. DE sera tratado como un vector de bloques del mismo tamano de bloque que DL,pero completamente vacıo.

3. Cualquier peticion enviada a la capa de E/S que tenga como destino DL, sera inter-ceptada y tratada adecuadamente.

4. El tratamiento de estas peticiones sera bastante similar al de la primera propuesta:

a) Si la peticion fuera de lectura:

1) Si no tiene que ver con datos modificados o nuevos, se terminara la inter-cepcion.

2) Si fuera sobre datos modificados, debera mapearse9 la peticion en don-de se encuentren realmente los datos. Concretamente, al soporte DE y,posiblemente, a otro bloque.

b) Si la peticion fuese de escritura:

1) Si fuera la primera vez que se escribe sobre esos bloques, se usarıan blo-ques libres de DE para almacenar la informacion. Una vez localizadosesos bloques, se utilizarıa esa informacion para modificar la peticion.

2) Si los bloques que se quisieran modificar ya lo hubieran sido previamente,se localizarıan los bloques correspondientes en DE que contuvieran esainformacion. Igualmente, procederıa a modificarse la peticion.

5. Una vez que se termina la intercepcion, se devuelve la peticion convenientementemodificada y se deja al sistema E/S que la procese del todo.

Para poder interceptar las peticiones de E/S es necesario modificar el codigo encarga-do de su recepcion para que, tras unos mınimos chequeos rutinarios, y antes de enviarloa la cola de peticiones del dispositivo correspondiente, se proceda a invocar la funcionencargada de retocar los valores de la peticion si fuera necesario. Por ejemplo, ante unaescritura, una vez modificada la peticion, el sistema de E/S la enviarıa a DE en vez dedejar que siguiera su curso hasta DL sobrescribiendo los datos que se quisieran proteger.

De forma similar a la propuesta de modificacion del sistema de memoria, en este casohay que modificar el codigo, aunque solo ligeramente, de la capa de E/S de bloques.Por tanto, algunos de los inconvenientes del caso anterior se repiten: las interfaces entredistintas versiones pueden variar, lo que obliga a un mantenimiento continuado y, ademas,al ser un sistema crıtico, no se puede distribuir como un simple modulo.

Es mas, tener que tratar las opciones de montaje para saber que soporte se usara comoDE, obliga a modificar levemente el codigo de Ext2. Si se quiere dar soporte a otros

9A pesar de no ser su significado real aunque este relacionado, el verbo “mapear” se utilizara en esteproyecto para describir la operacion de consultar en una determinada estructura la posicion que debe ocuparcierto dato.

24

2.2 Propuestas

sistemas de ficheros, deberan estudiarse sus implementaciones para realizar la mismafuncion.

Al contrario que las otras soluciones, aquı el lımite no es el numero de bloques libresen DL sino el tamano de DE. Como DE podrıa usarse una particion, un disco entero ocualquier dispositivo de bloques similar. El contenido previo de DE se perderıa al reali-zarse las escrituras.

2.2.4. Dispositivo virtualEsta ultima propuesta, que se describira a continuacion y que tiene mucho en comun

con la inmediatamente anterior, sera la que finalmente se acepte como solucion. Basica-mente consiste en la creacion de un nuevo tipo de dispositivo de bloques virtual (DV) quesera manejado por una aplicacion de usuario (ver figura 2.8).

Figura 2.8: Modificacion propuesta: dispositivo virtual.

Este nuevo dispositivo se colocara encima de DL y DE. Cualquier peticion que lellegue sera tratada y enviada al dispositivo correspondiente, de manera practicamente si-milar a como se hacıa al interceptar las peticiones de E/S. Los beneficios con respecto a lasolucion anterior residen en que no es necesario tocar ningun sistema del nucleo, relajan-do bastante las restricciones que habıa referentes a que futuros cambios en los sistemasmodificados (VMM y BIO) afectasen a la solucion y permitiendo la distribucion de lasolucion como modulo.

Para que esta propuesta funcione es necesario que, de cara al sistema, el dispositivo seacomo una capa transparente sobre DL. Toda peticion que le llegue sera tratada y redirigida

25


a donde convenga, es decir, a DL en el caso de lecturas y a DE en el caso de escrituras ytambien en el de lecturas sobre datos modificados de DL.

Ademas, esta propuesta apenas esta ligada a los sistemas de ficheros que usen lossoportes, aunque sı deben cumplir ciertos requisitos mınimos:

El sistema de ficheros debe dividir todo el soporte en bloques del mismo tamano.

Todos los accesos a los bloques deben estar alineados tanto en tamano como enposicion. La unica excepcion sera un bloque inicial, de tamano fijo, que describa eltamano real del bloque de esa particion.

Al igual que en el resto de propuestas, las peticiones de lectura de datos no modi-ficados a DV seran propagadas, sin modificaciones, a DL, cambiando simplemente eldispositivo receptor de la peticion y encolando de nuevo la misma en el sistema de E/S. Silas peticiones dirigidas a DV fueran escrituras o accesos de lectura a escrituras realizadasanteriormente en DE, no debera modificarse solo el dispositivo receptor realmente de lapeticion (DE) sino que ademas, debera mapearse el bloque dado originalmente para DVcon su correspondiente en DE.

Esta propuesta creara un dispositivo virtual por cada pareja de soportes, uno que semantendra intacto (DL) y otro que almacenara las escrituras (DE). Mediante una aplica-cion de control sera posible crear estos dispositivos virtuales, destruirlos, modificarlos eincluso averiguar su estado.

Un objetivo adicional planteado para esta propuesta es la posibilidad de sincronizarel contenido de DE con DL. Es decir, que los cambios que se han realizado y que seperderıan al retornar al estado primigenio del soporte, se escriban en DL. Este nuevoaspecto serıa provechoso para el usuario ante cambios o modificaciones del SF que hansido correctas y que se quieran mantener.

Finalmente, resaltar que esta propuesta es claramente mas limpia que cualquiera delas anteriores, tanto por no modificar ningun sistema del nucleo como por ser facilmentecontrolable por parte del usuario. Ademas, como mas tarde se vera, esta propuesta permiteusar como almacenamiento de escrituras soportes tan dispares como discos de memoriaRAM y ficheros emulando dispositivos de bloques mediante loop device10.

10Permite emular un dispositivo usando un fichero. Por ejemplo, se puede emular un dispositivo de blo-ques como puede ser un disco de 10 GiB usando un fichero de 10 GiB.

26

Capıtulo 3

CONCEPTOS PRELIMINARES

3.1. IntroduccionEste capıtulo explicara algunos de los conceptos basicos de sistemas operativos que

han sido necesarios para el desarrollo del proyecto, aunque se centrara la explicacion enLinux por ser el sistema operativo destino elegido. Se mostraran los prototipos internosde Linux de aquellas funciones que implementen la funcionalidad explicada y se deta-llara como se usan y cuando conviene utilizar una funcion u otra.

3.2. LinuxLinux es un sistema operativo de estilo UNIX1 y es muy conocido por ser uno de los

proyectos abanderados de los movimientos Open Source2 y Free Software3. Su nombreprocede de su creador y principal desarrollador: Linus Torvalds.

Cuando se habla de GNU/Linux se hace referencia al nucleo Linux junto con lasutilidades del sistema y bibliotecas desarrolladas para el sistema operativo GNU.

MINIX es otro sistema operativo de estilo UNIX, escrito por Andrew S. Tanenbaumen 1987, que se usaba principalmente con fines academicos. Sus fuentes estaban dispo-nibles, permitiendo a cualquier estudiante de sistemas operativos disponer de un sistemafuncional y que pudiese modificar para su estudio. Su principal problema es que fue di-senado para sistemas de 16 bits y no se adaptaba muy bien a la emergente popularidad dela plataforma Intel 386 de 32 bits. Linus comenzo a crear Linux como un reemplazo nocomercial de MINIX. Ademas, decidio usar el modelo de nucleo monolıtico, en vez delmodelo micronucleo de MINIX.

Un micronucleo es un nucleo con un conjunto de llamadas al sistema mınimo: comu-nicacion entre procesos, gestion a bajo nivel del espacio de memoria, gestion de hilos,

1UNIX fue un sistema operativo disenado en 1969 en los Laboratorios Bell por Ken Thompson, DennisRitchie y Douglas McIlroy.

2Metodologıa de desarrollo que ofrece acceso al codigo fuente de un producto.3Se denomina ası al software que puede ser usado, estudiado y modificado sin restriccion alguna y que,

ademas, puede ser copiado o redistribuido ya sea modificado o no sin ningun tipo de restriccion.

27


etc. El resto de llamadas clasicas de un nucleo se implementan por medio de servidoresen espacio del usuario y que se apoyan en la funcionalidad proveıda por el micronucleopara poder desarrollar sus labores.

Un nucleo monolıtico agrupa todo el codigo que atiende las llamadas al sistema den-tro del espacio del nucleo y con privilegios de supervisor. El principal beneficio del mi-cronucleo es un nucleo mas pequeno, simple, facil de depurar y de mantener. Ademas, lacaıda de un servidor, por ejemplo, uno que provea de acceso a sistemas de ficheros Ext2,no da lugar a una caıda global del nucleo, que sı podrıa ocurrir con uno monolıtico. Porcontra, los nucleos monolıticos son mas rapidos, puesto que no tienen la sobrecarga adi-cional del intercambio de mensajes entre los distintos servidores ni con el micronucleo ala hora de atender una peticion.

Linux permite la carga y descarga de funcionalidades adicionales mediante modulos.Los modulos son fragmentos de codigo que aportan nueva funcionalidad al nucleo y cuyocometido suele ser el soporte de hardware adicional o el acceso a nuevos tipos de sistemasde ficheros. Al contrario que Microsoft Windows, la interfaz grafica no es parte del nucleo.

Es uno de los sistemas mas portados a otras arquitecturas y se encuentra en el 75 %4

de los sistemas que conforman Top5005.Esta escrito en su mayor parte en C6 con algunas partes en ensamblador y C++7 y

engloba casi cinco millones de lıneas de codigo. Se encuentra licenciado bajo GPL 2.La version utilizada para el desarrollo del proyecto ha sido la 2.6.18, que vio la luz

en septiembre del 2006. Una vez concluido el proyecto y comprobado que funcionabacorrectamente, se decidio actualizar el mismo para dar soporte a la ultima version dispo-nible: 2.6.24, publicada en enero del 2008.

3.3. Manejo de la memoriaLa memoria, como recurso basico y necesario en casi cualquier desarrollo software, se

maneja de manera similar, hasta cierto punto, a como se hace desde el espacio del usuario.En Linux, se dispone de las funciones kmalloc, vmalloc y alloc page (ver listado 3.1) parasolicitar memoria; las correspondientes para liberarla son kfree, vfree y free page.

La funcion kmalloc funciona de forma parecida a la funcion malloc de ANSI C: seindica la cantidad de memoria requerida como primer parametro. La diferencia se hallaen el segundo parametro, que identifica el tipo de memoria que se solicita y que puede serde varios tipos. He aquı los principales:

GFP ATOMIC: se usa para solicitar memoria desde una rutina de tratamiento de inte-rrupcion. No puede bloquearse.

4Estudio correspondiente a junio del 2008: http://www.top500.org/stats/list/31/os/5Top500 lista los 500 sistemas de computacion mas potentes conocidos: http://www.top500.

org/6C es un lenguaje de programacion de proposito general, estructurado en bloques, procedimental e

imperativo desarrollado en 1972 por Dennis Ritchie en los Laboratorios Bell.7C++ es un lenguaje de programacion derivado de C al que anade el paradigma de programacion orien-

tada a objetos.

28

3.3 Manejo de la memoria

GFP KERNEL: memoria normal del nucleo. Puede bloquearse.

GFP NOIO: al solicitarse la memoria, no puede producirse una operacion de E/S parapoder satisfacer la peticion. Puede bloquearse.

GFP USER: memoria en espacio de usuario. Puede bloquearse.

Listado 3.1: Asignar y liberar memoria.# i n c l u d e < l i n u x / s l a b . h>

vo id ∗ kmal loc ( s i z e t s i z e , g f p t f l a g s ) ;

vo id k f r e e ( c o n s t vo id ∗ ob jp ) ;

vo id ∗ vmal loc ( u n s i g n e d long s i z e ) ;

vo id v f r e e ( vo id ∗ add r ) ;

s t r u c t page ∗ a l l o c p a g e ( g f p t f l a g s ) ;

vo id f r e e p a g e ( s t r u c t page ∗ page ) ;

size: cantidad de memoria que se solicitara.

flags: tipo de memoria solicitada.

La coletilla de si la llamada puede bloquearse o no es importante. Para demostrarlo sepropone el siguiente ejemplo:

1. Una funcion del nucleo entra en una region crıtica protegida por un spin lock8.

2. Invoca la funcion kmalloc con un tipo de memoria que puede bloquear la peticion,por ejemplo GFP KERNEL.

3. El proceso se bloquea en esa funcion, cediendo voluntariamente el uso del procesa-dor.

4. El planificador elige otro proceso para que entre a ejecutar.

5. El proceso, a traves de una llamada al sistema, llega a ejecutar codigo del nucleo.

6. Al cabo de varias funciones, llega al mismo spin lock y se queda esperando que sele permita el paso a la region crıtica.

8Un spin lock es un mecanismo de sincronizacion donde un proceso simplemente espera en un buclerepetidamente hasta que se cumple una condicion. Se explicara con mas detalle en el punto 3.6

29


7. En un monoprocesador con Linux apropiativo, el sistema seguirıa ejecutando y elproceso, bloqueado a la espera de memoria libre, seguirıa ahı hasta que se liberasememoria suficiente y ası finalizar la region crıtica. En cambio, en un multiproce-sador, se perderıa un procesador, pues este intentarıa entrar constantemente en laregion crıtica. Hasta que no se satisficiese la peticion de memoria, no se podrıacerrar la region crıtica y, por tanto, liberar el proceso que esta encadenado a la com-probacion del spin lock. Una vez este proceso salga de la region crıtica, volverıa aquedar disponible ese procesador para el resto de procesos.

Por tanto, es importante no invocar funciones que puedan bloquearse dentro de regio-nes crıticas, para no dar lugar a un bloqueo, aunque sea de manera temporal. Se ahon-dara mas en las herramientas que ofrece el nucleo para tratar con los clasicos problemasde sincronizacion y acceso concurrente a estructuras en el punto 3.6.

El tipo GFP NOIO suele ser utilizado por los controladores de los dispositivos de blo-ques para evitar llamadas eternamente recursivas, ya que el proceso, al solicitar memoriade este tipo, impone la condicion de que no se produzcan operaciones de E/S para atenderla peticion. La motivacion para usar este tipo de memoria es la siguiente:

1. Llega una peticion de lectura al dispositivo A.

2. El controlador del dispositivo solicita memoria mediante kmalloc para sus gestionesinternas y ası poder tratar la solicitud.

3. No hay memoria disponible, por lo que el sistema de memoria virtual decide expul-sar de memoria unos bloques modificados del mismo dispositivo A.

4. Por tanto, esos bloques se envıan al controlador del dispositivo para que los escribaen el soporte.

5. Para escribirlos, necesita memoria que solicita y vuelta a empezar.

El resultado evidente es que no habra fin para la solicitud de memoria, a menos quese consiga liberar de otra forma: desechando bloques no modificados en memoria, datosen cache, etc. Para evitar esta situacion, al solicitar memoria, se anade la siguiente restric-cion: la funcion encargada de localizar memoria libre no puede emplear operaciones deE/S.

El uso de kmalloc solo se recomienda para peticiones inferiores a 128 KiB. Para ta-manos mayores, es preferible el uso de vmalloc o gestionar, de manera personalizada, lasdistintas paginas de memoria obtenidas mediante alloc page.

El funcionamiento de vmalloc es igual al de kmalloc: la diferencia radica en como segestiona internamente la solicitud de memoria. Cuando la peticion se hace mediante kma-lloc, la memoria obtenida se encuentra en paginas de memoria consecutivas fısicamente.Por el contrario, al pedirla a traves de vmalloc, la memoria se encontrara en paginas dememoria no contiguas fısicamente, aunque sı desde el punto de vista del espacio de me-moria virtual.

30

3.4 Informar al usuario

La memoria solicitada con kmalloc se libera con kfree mientras que vfree se usa parala solicitada con vmalloc.

A veces es preferible trabajar directamente con las paginas de memoria, paginas que sepueden solicitar mediante la funcion alloc page. Esta funcion recibe el ya clasico parame-tro que indica el tipo de memoria solicitada y que ya se explico anteriormente. El resultadode la funcion es una pagina de memoria, normalmente de 4 KiB.

Una vez que se termine de utilizar la pagina, se devuelve al nucleo mediante la funcionfree page.

3.4. Informar al usuarioPara poder mostrar texto al usuario se utiliza la funcion printk. Su funcionamiento es

calcado al de la funcion printf de ANSI9 C, aunque tiene una diferencia importante: hayque indicar el nivel de alerta del mensaje. Dependiendo de este nivel de alerta, el mensajese almacenara en el registro de eventos o, adicionalmente, si fuera muy importante, semostrara al usuario por las consolas activas.

Listado 3.2: Niveles de alerta para printk.# d e f i n e KERN EMERG ‘‘<0>”# d e f i n e KERN ALERT ‘‘<1>”# d e f i n e KERN CRIT ‘‘<2>”# d e f i n e KERN ERR ‘‘<3>”# d e f i n e KERN WARNING ‘‘<4>”# d e f i n e KERN NOTICE ‘‘<5>”# d e f i n e KERN INFO ‘‘<6>”# d e f i n e KERN DEBUG ‘‘<7>”

i n t p r i n t k ( c o n s t c h a r ∗ fmt , . . . ) ;

A continuacion el significado de cada uno de los niveles:

KERN EMERG: mensajes de emergencia, normalmente aquellos que preceden a unacaıda del sistema.

KERN ALERT: situaciones que requieren una accion inmediata.

KERN CRIT: condiciones crıticas, a menudo relacionadas con fallos hardware o sof-tware.

KERN ERR: condiciones de error.

KERN WARNING: situaciones problematicas, pero que no deberıan crear problemasgraves al sistema.

9American National Standards Institute o Instituto de Estandares Nacionales Americanos.

31


KERN NOTICE: situaciones normales, pero que merece la pena notificar como avisosrelacionados con la seguridad del sistema.

KERN INFO: mensajes informativos: utilizado por muchos controladores durante suinicializacion para informar del hardware que han encontrado.

KERN DEBUG: mensajes de depuracion.

3.5. Gestion de erroresLa gestion de errores en el nucleo se lleva a cabo usando la palabra reservada goto del

lenguaje C. El uso de esta palabra siempre ha sido muy criticado por dar lugar a codigodifıcil de leer y mantener, pues altera el flujo de ejecucion y obliga al programador a saltarde funcion en funcion, en vez de encapsular la logica en funciones e invocarlas segun serequiera.

En cambio, en la gestion de errores su uso evita que se replique el codigo dedicadoa deshacer y/o liberar recursos una vez falla la peticion de acceso a uno de ellos. Comomuestra, comparese el listado 3.3 con 3.4.

Listado 3.3: Ejemplo sin goto.i n t i n i t m y i n i t f u n c t i o n ( vo id ){

i n t e r r ;

/∗ r e g i s t r a t i o n t a k e s a p o i n t e r and a name ∗ /e r r = r e g i s t e r t h i s ( p t r 1 , ” foo ” ) ;i f ( e r r )

r e t u r n e r r ;e r r = r e g i s t e r t h a t ( p t r 2 , ” b a r ” ) ;i f ( e r r ) {

u n r e g i s t e r t h i s ( p t r 1 , ” foo ” ) ;r e t u r n e r r ;

}e r r = r e g i s t e r t h o s e ( p t r 3 , ” f o o b a r ” ) ;i f ( e r r ) {

u n r e g i s t e r t h a t ( p t r 2 , ” b a r ” ) ;u n r e g i s t e r t h i s ( p t r 1 , ” foo ” ) ;r e t u r n e r r ;

}r e t u r n 0 ; /∗ s u c c e s s ∗ /

}

32

3.6 Concurrencia y condiciones de carrera

Listado 3.4: Ejemplo con goto.i n t i n i t m y i n i t f u n c t i o n ( vo id ){

i n t e r r ;

/∗ r e g i s t r a t i o n t a k e s a p o i n t e r and a name ∗ /e r r = r e g i s t e r t h i s ( p t r 1 , ” foo ” ) ;i f ( e r r ) go to f a i l t h i s ;e r r = r e g i s t e r t h a t ( p t r 2 , ” b a r ” ) ;i f ( e r r ) go to f a i l t h a t ;e r r = r e g i s t e r t h o s e ( p t r 3 , ” f o o b a r ” ) ;i f ( e r r ) go to f a i l t h o s e ;

r e t u r n 0 ; /∗ s u c c e s s ∗ /

f a i l t h o s e : u n r e g i s t e r t h a t ( p t r 2 , ” b a r ” ) ;f a i l t h a t : u n r e g i s t e r t h i s ( p t r 1 , ” foo ” ) ;f a i l t h i s : r e t u r n e r r ; /∗ p r o p a g a t e t h e e r r o r ∗ /}

Es claramente mas intuitivo el listado 3.4 que el 3.3. Ademas, si hay que corregiralguna variable o nombre de funcion, es mas facil, y menos propenso a errores, hacerloen un unico bloque, el ultimo, que ir revisando todos los posibles bloques.

3.6. Concurrencia y condiciones de carrera

3.6.1. IntroduccionEn la rama 2.4 del nucleo Linux, cuando a un proceso que estaba ejecutando codigo

del nucleo se le acababa su porcion de tiempo asignado, lo normal era esperar a que invo-case una llamada bloqueante o decidiese retornar al espacio de usuario. En ese momento,el nucleo podıa realizar un cambio de contexto y poner a ejecutar a otro proceso.

A partir de la rama 2.6 de Linux, el nucleo es apropiativo o preemptive, es decir,en cualquier momento, un proceso ejecutando codigo del nucleo puede ser expulsado ysustituido por otro proceso cualquiera. Este cambio plantea una serie de problemas, sobretodo con el acceso a variables globales o compartidas: las condiciones de carrera. Porejemplo:

1. Un proceso A que esta ejecutando codigo del nucleo decide incrementar un conta-dor global.

2. El proceso A lee el valor en un registro y lo incrementa.

3. Es expulsado en el momento que va a actualizar el contador global.

4. El proceso B que entra a ejecutar decide decrementar el mismo contador.

33


5. El proceso B lleva a cabo la tarea y cede el procesador.

6. El proceso A reanuda su ejecucion y, al actualizar el contador, escribe datos que noson correctos, pues no ha tenido en cuenta el decremento del proceso B.

Para eliminar estos problemas y otros muy relacionados, como son el acceso con-currente a la misma estructura al ejecutar el mismo codigo en distintos procesadores demanera simultanea, el nucleo provee de herramientas de sincronizacion entre procesos.Estas herramientas ayudan a crear regiones crıticas, donde se garantiza la atomicidadde las operaciones contenidas dentro de ellas. Las herramientas mas utilizadas son lossemaforos y los spin lock y su funcionamiento, al igual que con muchas de las funcionesya comentadas, es muy similar a sus contrapartidas disponibles en el espacio de usuario.

3.6.2. Semaforos

Un semaforo es un contador combinado con dos funciones: down y up. Cuando sequiere entrar en una region crıtica, el proceso invoca la funcion down. Si el contador esmayor que cero, el proceso continua su ejecucion. Una vez dentro, realiza sus laboresy termina invocando la funcion up, la cual pone fin a la region crıtica incrementando elvalor del contador.

Si el valor del contador es cero cuando un proceso ejecuta down, entonces, este essuspendido a la espera de que otro proceso, dentro de la region crıtica, libere el semaforo.

El valor del contador con el que se crea el semaforo sirve de indicativo de cuantosprocesos pueden entrar en la misma region crıtica. Un caso particular de los semaforoses aquel cuyo valor inicial es uno. En este tipo de semaforos, tambien conocidos comomutex, solo se permite un proceso dentro de la region crıtica.

Los semaforos son creados usando la funcion sema init, donde el primer parametro esel semaforo que se va a crear y el segundo el valor inicial de salida del mismo.

Listado 3.5: Operar con semaforos.# i n c l u d e <asm / semaphore . h>

vo id s e m a i n i t ( s t r u c t semaphore ∗sem , i n t v a l ) ;

vo id down ( s t r u c t semaphore ∗ sem ) ;

vo id up ( s t r u c t semaphore ∗ sem ) ;

Existe un caso particular de semaforos conocido como “semaforos lectura/escritura”.En estos semaforos, no se discrimina segun el valor del contador sino dependiendo deltipo de operacion que se quiera llevar a cabo: si el codigo de la region crıtica va a con-sistir en lecturas concurrentes sobre estructuras o variables compartidas, entonces no hayproblema, pueden entrar cuantos procesos quieran. En cambio, si se trata de una escritura,solo puede pasar uno, puesto que solo tiene sentido que un proceso realice modificaciones.

34

3.6 Concurrencia y condiciones de carrera

Este tipo de semaforos puede optimizar bastante el rendimiento si hay muchas maspeticiones de lectura que escritura, ya que todas las lecturas pueden acceder concurrente-mente. Como pueden coincidir muchas lecturas a la vez y para evitar inanicion por partede las peticiones de escritura, se suele dar mayor prioridad a estas ultimas. En cambio, elproblema de la inanicion podrıa pasarse a las lecturas si hubiera demasiadas escrituras oestas tardasen mucho en salir de la region crıtica. Por tanto, este tipo de semaforos no esmuy utilizado, a no ser que apenas haya accesos de escritura.

Finalmente, la funcion de inicializacion de este tipo de semaforos es init rwsem yrecibe como unico parametro una estructura que representa al semaforo a crear.

Listado 3.6: Operar con semaforos lectura/escritura.# i n c l u d e < l i n u x / rwsem . h>

vo id i n i t r w s e m ( s t r u c t rw semaphore ∗sem ) ;

vo id d o w n r e a d ( s t r u c t rw semaphore ∗sem ) ;

vo id d o w n w r i t e ( s t r u c t rw semaphore ∗sem ) ;

vo id u p r e a d ( s t r u c t rw semaphore ∗sem ) ;

vo id u p w r i t e ( s t r u c t rw semaphore ∗sem ) ;

3.6.3. Spin lock

A diferencia de los semaforos que suspenden al proceso mientras espera que le per-mitan pasar dentro de la region crıtica, los spin lock realizan una espera activa, es decir,se quedan esperando a que se les permita el paso. Son ideales para esperas cortas dondela sobrecarga de dormir y despertar un proceso no merezca la pena.

El funcionamiento de los spin lock es muy simple y se basa en la lectura y comproba-cion del valor de una variable. Esta variable es la encargada de permitir o denegar el pasoa la region crıtica en funcion del estado que indique. Obviamente, el proceso de consultade la variable, y modificacion, si se permite el paso, es atomico para evitar que variosprocesos entren a la vez dentro de la region crıtica.

Para crear un spin lock se utiliza la funcion spin lock init que recibe como unicoparametro una estructura que representara al spin lock. Para intentar entrar en la regioncrıtica se usa la funcion spin lock. Una vez se quiera terminar y liberar el spin lock seusara la funcion spin unlock.

Es muy importante recalcar que un proceso que ha obtenido un spin lock, es decir,esta dentro de la region crıtica, no puede hacer llamadas bloqueantes, puesto que en esecaso cederıa el uso del procesador. Otro proceso podrıa intentar entrar en la misma regioncrıtica y bloquearse activamente esperando que se libere el paso protegido por el spinlock. Esto podrıa no suceder nunca, si el unico que puede hacerlo esta suspendido y elprocesador esta empleandose en acceder al spin lock.

35


Listado 3.7: Operar con spinlock.# i n c l u d e < l i n u x / s p i n l o c k . h>

vo id s p i n l o c k i n i t ( s p i n l o c k t ∗ l o c k ) ;

vo id s p i n l o c k ( s p i n l o c k t ∗ l o c k ) ;

vo id s p i n u n l o c k ( s p i n l o c k t ∗ l o c k ) ;

De manera similar a los semaforos, existe una variante de lectura/escritura para spinlock. Estos cierres permiten un numero cualquiera de procesos lectores dentro del spinlock, pero solo un escritor en solitario puede acceder a la seccion crıtica. Su utilizacion espracticamente igual a la de los spin lock clasicos.

Listado 3.8: Operar con spinlock lectura/escritura.# i n c l u d e < l i n u x / s p i n l o c k . h>

vo id r w l o c k i n i t ( r w l o c k t ∗ l o c k ) ;

vo id r e a d l o c k ( r w l o c k t ∗ l o c k ) ;

vo id r e a d u n l o c k ( r w l o c k t ∗ l o c k ) ;

vo id w r i t e l o c k ( r w l o c k t ∗ l o c k ) ;

vo id w r i t e u n l o c k ( r w l o c k t ∗ l o c k ) ;

36

Capıtulo 4

DESARROLLO EIMPLEMENTACION DE LASOLUCION

4.1. Introduccion

En este capıtulo se describira, en primer lugar, la construccion del controlador paso apaso, explicando los sistemas implicados, justificando las decisiones tomadas e ilustran-do, en la medida de lo posible, con fragmentos del codigo desarrollado. Este controladortendra una funcionalidad mınima: registrarse en el sistema, inicializar y detener el dis-positivo, permitir que se encolen las peticiones de E/S, etc. Tambien se explicaran lasestructuras creadas para el controlador, a fin de facilitar el seguimiento mediante los fi-cheros fuente del mismo.

Es necesario recalcar que, puesto que un desarrollo dentro del nucleo no suele ser muycorriente, se ha preferido dar un toque mas pedagogico a la documentacion, incorporan-do fragmentos de codigo del proyecto, ya sean funciones o estructuras. Aunque puedaparecer que entorpece la lectura el mezclar codigo con texto normal, ayuda a tener unamayor compresion del desarrollo, si despues de introducir un tema, este es acompanadode codigo, sobre todo si es codigo real de la solucion.

En este siguiente apartado es donde se mostrara como trata el controlador las peti-ciones que le llegan y como actua sobre ellas: a veces las fragmentara para enviarlas adistintos puntos del mismo dispositivo, o puede que a los dos dispositivos a la vez; otrasveces las encaminara hacia uno de los dispositivos sin modificar nada mas de la peticion.Ademas, se explicara con detalle la estructura de una peticion de E/S y como es atendidapor el controlador del dispositivo destino.

37

DESARROLLO E IMPLEMENTACION DE LA SOLUCION

4.2. Creacion del dispositivo virtual

4.2.1. Estructura de moduloNormalmente, al crear nuevos dispositivos para Linux, se les suele dar caracter de

modulo. Los modulos son ficheros de codigo objeto que permiten anadir nuevas fun-cionalidades o caracterısticas al nucleo. Ejemplos de software que se distribuyen comomodulos son los sistemas de ficheros y controladores para dispositivos hardware. Se ob-tienen al compilar los ficheros fuentes en lenguaje C y suelen hacer uso de los distintosmecanismos y sistemas del nucleo. El usuario, al compilar estos ficheros, puede elegirentre generar un modulo o integrarlos en la imagen del nucleo.

Para crear un modulo en Linux basta con definir dos funciones: una de inicializaciony otra de terminacion. La funcion de inicializacion tendra el prefijo init mientras quela de terminacion usara exit. El prefijo init le indica a Linux que esa funcion puedeser eliminada de memoria una vez ejecutada, para ası poder disponer de la memoria queocupaba. En cambio, el prefijo exit marca las funciones que podran ser desechadas alcompilar los fuentes dentro de la imagen de Linux en vez de como modulo. Si los fuentesvan a ser compilados como parte de la imagen del nucleo, no tiene sentido anadir todasaquellas funciones encargadas de tratar la eliminacion o descarga del modulo de memoria.

Ademas de los prefijos mostrados, se dispone de una serie de macros1 que el crea-dor del modulo puede usar para aportar mas informacion sobre el modulo. Algunas deellas son obligatorias como module init o module exit. Las macros disponibles, algunascompletamente en mayusculas y otras en minusculas, son las siguientes:

MODULE ALIAS BLOCKDEV MAJOR (major): el modulo da soporte a los dispo-sitivos que usen este major2.

MODULE AUTHOR (autor): datos del autor del modulo.

MODULE DESCRIPTION (descripcion): breve descripcion del modulo.

module exit (funcion de eliminacion): su unico parametro es el nombre de la funcionque se invocara cuando se quiera eliminar el modulo.

module init (funcion de entrada): su unico parametro es el nombre de la funcion quehace de punto de entrada al modulo.

MODULE LICENSE (licencia): el tipo de licencia de uso.

module param (nombre, tipo): para poder pasar distintas opciones al modulo durantela inicializacion se usa esta macro que recibe dos parametros. El primer parametroes el nombre de la variable que recibira el valor y el segundo es el tipo de esavariable.

1Una macro o macroinstruccion es una serie de instrucciones que se almacenan para que se puedanejecutar de forma secuencial mediante una sola llamada u orden de ejecucion.

2La explicacion sobre el valor major se dara en el siguiente punto.

38

4.2 Creacion del dispositivo virtual

MODULE PARM DESC (nombre, descripcion): permite describir el significado delos parametros de la macro anterior. Recibe dos parametros: el nombre del parame-tro y su descripcion.

MODULE SUPPORTED DEVICE (nombre): nombre del dispositivo al que dara so-porte este modulo. Por ahora no se utiliza.

MODULE VERSION (version): version del modulo.

Usando las macros descritas, el esqueleto del modulo quedarıa tal y como se ve en ellistado 4.1. La licencia escogida es la “GPL v2”3 y ademas el modulo puede recibir unparametro opcional que indique cuantos dispositivos virtuales se van a crear. Por defecto,crea solo uno.

Listado 4.1: Esqueleto de codigo del modulo# i n c l u d e < l i n u x / module . h># i n c l u d e < l i n u x / i n i t . h>

s t a t i c i n t 3 2 t max rbd = 1 ;

/∗ I n i c i a l i z a c i o n d e l d i s p o s i t i v o ∗ /s t a t i c i n t 3 2 t i n i t r b d i n i t ( vo id ){

/∗ Comprobar ”max rbd” ∗ /i f ( ( max rbd < 1) | | ( max rbd > 10) ) {

p r i n t k (KERN WARNING ” rbd : i n v a l i d max rbd ( must bebetween 1 and 10) , u s i n g d e f a u l t ( 1 ) .\ n ” ) ;

max rbd = 1 ;}

r e t u r n 0 ;}

/∗ E l i m i n a c i o n d e l d i s p o s i t i v o ∗ /s t a t i c vo id e x i t r b d e x i t ( vo id ){

r e t u r n ;}

m o d u l e i n i t ( r b d i n i t ) ;m o d u l e e x i t ( r b d e x i t ) ;

MODULE LICENSE ( ”GPL v2 ” ) ;

3http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt

39


MODULE AUTHOR ( ” R a f a e l Anton io P o r r a s Samaniego< r a f a @ d i s t r o b i t . ne t>” ) ;

MODULE DESCRIPTION ( ” C r e a t e s a r o l l b a c k dev i ce , u s e f u l f o rt e s t i n g and n o t d e f i n i t i v e w r i t i n g s . ” ) ;

module param ( max rbd , i n t , 0 ) ;MODULE PARM DESC ( max rbd , ”Maximum number o f r o l l b a c k d e v i c e s

(1 − 10) . D e f a u l t : 1 . ” ) ;MODULE ALIAS BLOCKDEV MAJOR (MAJOR RBD) ;MODULE SUPPORTED DEVICE ( ” rbd ” ) ;MODULE VERSION ( ” 0 . 1 ” ) ;

Una nota relacionada con el fragmento de codigo: todas aquellas funciones que nodeban ser visibles mas alla del fichero de codigo actual deberan llevar el prefijo static.

La mayorıa de los datos guardados mediante las macros pueden obtenerse usando laherramienta modinfo. En el listado 4.2 se puede ver el resultado de ejecutar modinfo sobreel modulo definido anteriormente.

Listado 4.2: Ejemplo de modinfof i l e n a m e : rbd . kov e r s i o n : 0 . 1a l i a s : b lock−major −240−∗d e s c r i p t i o n : C r e a t e s a r o l l b a c k dev ice , u s e f u l f o r t e s t i n g

and n o t d e f i n i t i v e w r i t i n g s .a u t h o r : R a f a e l Anton io P o r r a s Samaniego

< r a f a @ d i s t r o b i t . ne t>l i c e n s e : GPL v2s r c v e r s i o n : 93D79F8BB4CAAE0CBADC922depends :ve rmag ic : 2 . 6 . 2 4 . 3 preempt mod unloadparm : max rbd : Maximum number o f r o l l b a c k d e v i c e s (1 −

10) . D e f a u l t : 1 . ( i n t )

Como ultimo apunte, indicar que lo deseable es situar, en la medida de lo posible, lamayor cantidad de codigo en espacio del usuario, en vez de en el modulo: por simplicidada la hora de desarrollar y depurar, para poder utilizar bibliotecas de todo tipo y, sobre todo,porque utilizar un puntero sin inicializar se traduce en el fin de la aplicacion4, mientrasque en el nucleo puede degenerar en un kernel panic5 que derrumbe todo el sistema.

4.2.2. Registro del dispositivoEn Linux, todos los dispositivos que se encuentran en el directorio /dev estan identifi-

cados por:

Un major number que identifica al tipo de dispositivo.4En estos casos, la aplicacion suele terminar abruptamente con el siguiente mensaje: Segmentation fault.5Es un mensaje mostrado por el SO una vez detectado un error interno de sistema del cual no puede

recuperarse.

40


Un minor number que suele identificar distintas instancias del dispositivo.

Un indicador de si el dispositivo es de caracteres (letra ‘c’) o de bloques (letra‘b’). Los dispositivos de caracteres ofrecen un acceso de caracter en caracter y nosuelen permitir el acceso aleatorio a los datos (terminales, modem, secuenciadorde sonido, etc). Los dispositivos de bloques, en cambio, permiten acceder, ya seasecuencialmente o de manera aleatoria, a los datos mediante bloques (discos duros,DVD, etc).

En el listado 4.3 se puede observar como el secuenciador de sonido es un dispositivode caracteres (letra ‘c’ en la primera columna) con un major 14 y un minor 1. Tambienaparece un disco duro SATA6 como dispositivo de bloques (letra ‘b’) y cuyo major es 8 ysu minor es 0.

Listado 4.3: Extracto del directorio /devbrw−r−−−−− 1 r o o t d i s k 8 , 0 a b r 29 16 :36 / dev / sdacrw−rw−−−− 1 r o o t a u d i o 14 , 1 a b r 29 16 :36 / dev / s e q u e n c e r

El dispositivo virtual que se va a crear es de bloques y, al no tener un major asignadopor convenio, necesitara de uno propio. Este valor se asocia al tipo de dispositivo en elmomento de registrarlo en el sistema mediante la funcion register blkdev (ver listado 4.4).

Listado 4.4: Funcion de registro del dispositivo de bloques.# i n c l u d e < l i n u x / f s . h>

i n t r e g i s t e r b l k d e v ( u n s i g n e d i n t major , c o n s t c h a r ∗name )

major: major que se quiere para el dispositivo. Si su valor fuera 0, el sistema retornarıauno libre.

name: nombre del tipo de dispositivo con el que aparecera listado en /proc/devices.

Al revisar el documento Documentation/devices.txt de Linux, que lista los major asig-nados a cada dispositivo en Linux, se observo que existıa un rango de major reservadopara uso local. En concreto, el rango va de 240 a 254, ası que se tomo el valor 240 comomajor del dispositivo que se esta desarrollando. Por tanto, en el listado 4.5, la constanteMAJOR RBD vale 240 y se procede a registrar el dispositivo rbd en la funcion rbd init;la funcion rbd exit se encargara de deshacer el registro y de liberar el major.

6Serial ATA es una interfaz de transferencia de datos entre la placa base y algunos dispositivos dealmacenamiento como discos duros, disquetes, etc. Su principal diferencia con PATA o Parallel ATA es lareduccion del numero de hilos empleados en la comunicacion pasando de usar 40 a solo 7.

41


Listado 4.5: Registro del dispositivo de bloques.s t a t i c i n t 3 2 t i n i t r b d i n i t ( vo id ){. . .

/∗ Obtener ”major” ∗ /major = r e g i s t e r b l k d e v (MAJOR RBD, ” rbd ” ) ;i f ( major < 0) {

p r i n t k (KERN ERR ” rbd : u n a b l e t o g e t major number%d . \ n ” , MAJOR RBD) ;

r e t u r n −EBUSY;}

. . .}

s t a t i c vo id e x i t r b d e x i t ( vo id ){. . .

/∗ D e v o l v e r ”major” ∗ /u n r e g i s t e r b l k d e v (MAJOR RBD, ” rbd ” ) ;

. . .}

4.2.3. Disco virtualEl dispositivo virtual que se va a crear sera un disco duro virtual situado encima de

dos soportes: uno que solo permitira lecturas y otro que almacenara las escrituras y laslecturas sobre estas.

Para crear dispositivos de bloques, Linux provee de un API especıfica para simpli-ficar su generacion y manejo. Estos dispositivos son descritos mediante una estructuragendisk cuyos campos (solo se muestran los mas importantes en el listado 4.6) deben serinicializados en primer lugar por el nucleo. La funcion alloc disk se encarga de esta ini-cializacion y retorna la estructura lista para usar. Despues sera el turno, para el codigo quesolicito la estructura, de terminar de rellenar los campos restantes antes de poner el discoa disposicion del sistema mediante la funcion add disk.

Cuando se quiera eliminar el dispositivo, debera invocarse la funcion del gendisk pararetirarlo del sistema. Una vez hecho, la estructura sera devuelta al nucleo mediante lafuncion put disk.

42


Listado 4.6: Estructura gendisk.# i n c l u d e < l i n u x / genhd . h>

s t r u c t g e n d i s k {i n t major ;i n t f i r s t m i n o r ;i n t minors ;c h a r d i sk name [ 3 2 ] ;s t r u c t b l o c k d e v i c e o p e r a t i o n s ∗ f o p s ;s t r u c t r e q u e s t q u e u e ∗ queue ;vo id ∗ p r i v a t e d a t a ;s e c t o r t c a p a c i t y ;i n t f l a g s ;

} ;

s t r u c t g e n d i s k ∗ a l l o c d i s k ( i n t minors ) ;

vo id a d d d i s k ( s t r u c t g e n d i s k ∗gd ) ;

vo id d e l g e n d i s k ( s t r u c t g e n d i s k ∗gd ) ;

vo id p u t d i s k ( s t r u c t g e n d i s k ∗ d i s k ) ;

vo id s e t c a p a c i t y ( s t r u c t g e n d i s k ∗ d i sk , s e c t o r t s i z e ){

d i sk−>c a p a c i t y = s i z e ;}

major: major del dispositivo tal y como se explico en el punto 4.2.2.

first minor: minor que diferencia esta instancia del dispositivo.

minors: el numero de particiones que permite el dispositivo.

disk name: nombre del dispositivo.

fops: apunta al conjunto de funciones encargadas de tratar ciertas operaciones sobre eldispositivo.

queue: cola de peticiones para este dispositivo; de ella se hablara mas adelante en elpunto 4.2.4.

private data: guarda informacion propia del dispositivo.

capacity: almacena la capacidad del disco medida en sectores de 512 bytes. Este valordebe ser fijado mediante la funcion set capacity.

43


flags: indica distintas peculiaridades del disco, como por ejemplo si permite o no parti-ciones.

Aunque existen discos con un tamano de sector distinto de 512 bytes, este suele ser elmas comun. Por ello, Linux visualiza cada dispositivo como una lista de sectores de 512bytes, dejando en manos del controlador del hardware la tarea de traducir las posicionesentre ese tamano y el propio del dispositivo.

Es ya clasico en Linux habilitar soporte en caliente para nuevos objetos, como disposi-tivos o sistemas de ficheros, definiendo una interfaz de funciones. Todo objeto que quieraser cargado en memoria en tiempo de ejecucion necesitara ser enganchado al nucleo pormedio de punteros a funciones. En nuestro caso, el campo fops apuntara a las funcionesencargadas de tratar las distintas operaciones (ver listado 4.7) sobre el dispositivo, aunquesolo se explicaran aquellas que resulten necesarias para el desarrollo del mismo.

Listado 4.7: Plantilla de operaciones de un dispositivo de bloques.# i n c l u d e < l i n u x / f s . h>

s t r u c t b l o c k d e v i c e o p e r a t i o n s {i n t (∗ open ) ( s t r u c t i n o d e ∗ , s t r u c t f i l e ∗ ) ;i n t (∗ r e l e a s e ) ( s t r u c t i n o d e ∗ , s t r u c t f i l e ∗ ) ;i n t (∗ i o c t l ) ( s t r u c t i n o d e ∗ , s t r u c t f i l e ∗ , uns igned ,

u n s i g n e d long ) ;l ong (∗ u n l o c k e d i o c t l ) ( s t r u c t f i l e ∗ , uns igned , u n s i g n e d

long ) ;l ong (∗ c o m p a t i o c t l ) ( s t r u c t f i l e ∗ , uns igned , u n s i g n e d

long ) ;i n t (∗ d i r e c t a c c e s s ) ( s t r u c t b l o c k d e v i c e ∗ , s e c t o r t ,

u n s i g n e d long ∗ ) ;i n t (∗ media changed ) ( s t r u c t g e n d i s k ∗ ) ;i n t (∗ r e v a l i d a t e d i s k ) ( s t r u c t g e n d i s k ∗ ) ;i n t (∗ g e t g e o ) ( s t r u c t b l o c k d e v i c e ∗ , s t r u c t hd geomet ry ∗ ) ;s t r u c t module ∗owner ;

} ;

El listado 4.8 muestra la creacion y la destruccion del dispositivo. Como en este dis-positivo no se permitiran particiones, se inicializa el campo minors con el valor 1 y sehabilita el flag GENHD FL SUPPRESS PARTITION INFO en el campo flags. El nombredel dispositivo constara del prefijo “rbd” seguido de un numero que identifica la instancia.El campo private data apunta a una estructura particular de cada instancia que contieneinformacion que le afecta solamente a ella. Esta estructura sera explicada mas detallada-mente en el punto 4.2.6.1. Finalmente, la capacidad no se indica, puesto que se desconoce;hasta que no se conozca cual es el tamano del soporte que se protegera, sera imposibledar el tamano del disco, pues deben coincidir completamente.

44


Listado 4.8: Creacion y destruccion del dispositivo.

/∗ Crea un d i s p o s i t i v o con e l ”minor” i n d i c a d o ∗ /s t a t i c s t r u c t r o l l b a c k d e v ∗ r b d c r e a t e ( i n t 3 2 t i ){. . .

d e v t c l a v e = MKDEV (MAJOR RBD, i ) ;s t r u c t g e n d i s k ∗ d i s c o ;

/∗ Crear e l d i s c o f i c t i c i o ∗ /d i s c o = a l l o c d i s k ( 1 ) ;i f ( ! d i s c o ) {

p r i n t k (KERN ERR ” rbd : u n a b l e t o c r e a t e f i c t i t i o u sd e v i c e .\ n ” ) ;

r e t u r n ERR PTR(−ENOMEM) ;}d i s c o−>major = MAJOR ( c l a v e ) ;d i s c o−>f i r s t m i n o r = MINOR ( c l a v e ) ;s p r i n t f ( d i s c o−>disk name , ” rbd %d ” , MINOR ( c l a v e ) ) ;d i s c o−>f o p s = &r o l l b a c k o p s ;d i s c o−>p r i v a t e d a t a = ( vo id ∗ ) dev ;d i s c o−>f l a g s |= GENHD FL SUPPRESS PARTITION INFO ;a d d d i s k ( dev−>d i s c o ) ;

. . .}

/∗ E l i m i n a t o d o s l o s d i s p o s i t i v o s ∗ /s t a t i c vo id rbd remove ( vo id ){. . .

d e l g e n d i s k ( dev−>d i s c o ) ;p u t d i s k ( dev−>d i s c o ) ;

. . .}

/∗ Operac iones d e l d i s p o s i t i v o ∗ /s t a t i c s t r u c t b l o c k d e v i c e o p e r a t i o n s r o l l b a c k o p s = {

. owner = THIS MODULE ,

. open = r o l l b a c k o p e n ,

. r e l e a s e = r o l l b a c k r e l e a s e ,

. i o c t l = r o l l b a c k i o c t l ,

. g e t g e o = r o l l b a c k g e t g e o ,} ;

45


4.2.3.1. Metodo open

Se encarga de tramitar la apertura del dispositivo para poder acceder a el. En nuestrocaso, al ser un dispositivo virtual, su unica labor consiste en incrementar un contador deaperturas. De esta forma, se impide eliminar el dispositivo mientras no se hayan cerradotodas las peticiones de apertura.

Listado 4.9: Metodo open del dispositivo./∗ A b r i r e l d i s p o s i t i v o ∗ /s t a t i c i n t 3 2 t r o l l b a c k o p e n ( s t r u c t i n o d e ∗ inode , s t r u c t f i l e

∗ f i l p ){

s t r u c t r o l l b a c k d e v ∗ dev =inode−>i b d e v−>b d d i s k−>p r i v a t e d a t a ;

a t o m i c i n c (&dev−>u s u a r i o s ) ;r e t u r n 0 ;

}

4.2.3.2. Metodo release

Se encarga del cierre del dispositivo. En nuestro caso, decrementa el contador de aper-turas.

Listado 4.10: Metodo release del dispositivo./∗ Cerrar e l d i s p o s i t i v o ∗ /s t a t i c i n t 3 2 t r o l l b a c k r e l e a s e ( s t r u c t i n o d e ∗ inode , s t r u c t

f i l e ∗ f i l p ){

s t r u c t r o l l b a c k d e v ∗ dev =inode−>i b d e v−>b d d i s k−>p r i v a t e d a t a ;

a t o m i c d e c (&dev−>u s u a r i o s ) ;r e t u r n 0 ;

}

4.2.3.3. Metodo getgeo

Devuelve la geometrıa CHS7 del disco. Esta informacion solo tiene sentido cuando seha inicializado el dispositivo y, por tanto, se conoce el numero de sectores del dispositivode lecturas.

7Cilindro-cabeza-sector”, del ingles Cylinder-Head-Sector, es un metodo para acceder a un determinadosector del disco mediante estas tres coordenadas.

46


Los valores CHS que devuelve se calculan siempre igual:

Cabezas: 2.

Sectores: 4.

Cilindros: tantos como sectores tenga el dispositivo en el que se basa el nuestro,divididos entre ocho.

Listado 4.11: Metodo getgeo del dispositivo./∗ Obtener g e o m e t r i a d e l d i s p o s i t i v o ∗ /s t a t i c i n t 3 2 t r o l l b a c k g e t g e o ( s t r u c t b l o c k d e v i c e ∗ bdev ,

s t r u c t hd geomet ry ∗ geo ){

s t r u c t r o l l b a c k d e v ∗ dev = bdev−>b d d i s k−>p r i v a t e d a t a ;

/∗ Geometr ia tomada de md / md . c ∗ /geo−> s t a r t = 0 ;geo−>heads = 2 ;geo−>s e c t o r s = 4 ;geo−>c y l i n d e r s = g e t c a p a c i t y ( dev−>d i s c o ) / 8 ;r e t u r n 0 ;

}

4.2.3.4. Metodo ioctl

Su funcion es tratar las peticiones ioctl, que se explicaran detenidamente en el punto4.2.5. Estas peticiones ioctl sirven para interactuar con el dispositivo y ası poder contro-larlo mediante comandos, por ejemplo, para crear o eliminar dispositivos virtuales.

4.2.4. Cola de peticionesToda peticion de acceso a un dispositivo de bloques se coloca en una cola de peticiones

del dispositivo. Esta cola sirve para poder realizar las peticiones de manera asıncrona. Porejemplo, en el caso de una peticion de escritura de una aplicacion, se encola la peticion yla aplicacion puede seguir trabajando en vez de esperar bloqueada. Ademas, al encolar lapeticiones se puede optimizar la forma de tratarlas. Esta optimizacion se consigue si, envez de servir y atender las peticiones segun llegan, se procede a:

1. Fusionar aquellas peticiones que acceden a sectores colindantes.

2. Reordenar las peticiones de forma que el movimiento realizado al final por loscabezales sea mınimo. Por ejemplo, en vez de atender una peticion en el bordedel disco, luego una interior y finalmente una a medio camino, serıa mucho masrentable en tiempo acceder de fuera hacia dentro, es decir, empezando en la masexterior, seguir con la del medio y terminar con la peticion interior.

47


El principal beneficio es la reduccion de los tiempos de acceso para satisfacer lasdistintas peticiones y, como beneficio adicional, reducir el desgate mecanico.

Los encargados de reordenar y/o fusionar las peticiones son conocidos como planifi-cadores de E/S y Linux ofrece varios de ellos:

Anticipatory: este algoritmo intenta maximizar el rendimiento anticipandose a las lec-turas sıncronas.

Normalmente, los procesos leen datos de un soporte y, una vez han sido procesa-dos, vuelven a leer del soporte. Con un planificador mas conservador, este tipo desituacion producirıa que, ante una aparente finalizacion en la lectura de datos, seatendiese las peticiones de otro proceso. Si despues de que empiece a atenderseel otro proceso, el primero vuelve a solicitar datos, se producirıa una pequena so-brecarga de busqueda y acceso a disco. Habrıa sido mas rentable terminar con laspeticiones del primer proceso antes de mover las cabezas a la zona de trabajo delsegundo proceso.

La solucion que propone este algoritmo es esperar unos pocos milisegundos des-pues de completar las peticiones de un proceso, por si acaso enviara algunas mas ala cola.

Este planificador no se recomienda en sistemas RAID por hardware.

Deadline: este planificador intenta garantizar que cada peticion sera servida antes de untiempo lımite, normalmente 500 ms para las peticiones de lectura y 5 s para lasescrituras. Las lecturas tienen preferencia sobre las escrituras, puesto que ante unalectura los procesos se suelen bloquear a la espera de los datos.

Utiliza dos colas de tiempo lımite y dos para las peticiones ordenadas. La duplicidadse debe al distinto tratamiento que se da a la peticion si es lectura o si es escritura.Las colas de tiempo lımite se ordenan por su tiempo de expiracion y las otras por elnumero de sector.

Cuando se decide atender una peticion, el planificador comprueba la cola de tiem-po lımite para ver si alguna peticion ha expirado y, si es ası, atenderla. En casocontrario, comprueba la cola normal, dando siempre prioridad a las lecturas.

Este planificador suele recomendarse para sistemas con bases de datos.

CFQ o Completely Fair Queuing: este planificador encola cada peticion sıncrona enuna cola particular de cada proceso. Despues, da a cada cola un tiempo definidopara que complete el mayor numero de peticiones posibles. La duracion de estetiempo y el numero de peticiones que puede tener encoladas un proceso depen-de de la prioridad de E/S del mismo. Dependiendo de su prioridad, las peticionesasıncronas son encoladas todas juntas en unas pocas colas.

Aunque su objetivo no es funcionar como el planificador Anticipatory, consigueel mismo resultado, puesto que, al terminar de servir las peticiones de un proceso,el planificador queda a la espera de que lleguen mas del mismo mientras no seconsuma del todo su porcion de tiempo.

48


Noop: es un planificador muy simple que solo fusiona aquellas peticiones adyacentes enel disco, sin preocuparse de reordenar la cola de peticiones.

Todo dispositivo de bloques tiene una cola de peticiones donde operan estos algorit-mos con el fin de optimizar las operaciones de E/S, pero hay casos en los que es inutil.Uno de esos casos es este proyecto o aquel caso en el que el dispositivo es un RAID8,ya que no existe el dispositivo realmente, sino que las peticiones que les lleguen seranredistribuidas a otros dispositivos fısicos que sı sacaran provecho de estos algoritmos.

Por tanto, solo requieren de una cola de peticiones en el sentido de que necesitan queles lleguen las peticiones, pero no seran tratadas por el nucleo para optimizar el acceso aldispositivo.

El primer paso para que nuestro dispositivo disponga de una cola es crear una me-diante la funcion blk alloc queue. Esta funcion recibe como parametro el tipo de memo-ria9 que se usara, normalmente memoria estandar del nucleo o GFP KERNEL; devuelvela cola creada o error si hubo fallo. Para devolver la cola al sistema se usa la funcionblk put queue.

Listado 4.12: Gestion de colas de dispositivo.# i n c l u d e < l i n u x / b lkd ev . h>

r e q u e s t q u e u e t ∗ b l k a l l o c q u e u e ( g f p t gfp mask ) ;

vo id b l k q u e u e m a k e r e q u e s t ( s t r u c t r e q u e s t q u e u e ∗ q ,m a k e r e q u e s t f n ∗ mfn ) ;

i n t ( m a k e r e q u e s t f n ) ( s t r u c t r e q u e s t q u e u e ∗q , s t r u c t b i o∗ b i o ) ;

vo id b l k p u t q u e u e ( s t r u c t r e q u e s t q u e u e ∗q ) ;

q: cola a la que se le asociara la funcion.

mfn: funcion a asociar a la cola, que debera ser como la funcion make request fn.

Una vez que se dispone de la cola es necesario asociarle una funcion propia que seencargara de gestionar las peticiones que lleguen a la misma. La asociacion de la cola conla funcion deseada se realiza mediante la funcion blk queue make request. En nuestrocaso, se han desarrollado dos funciones:

8Acronimo de “Conjunto redundante de discos baratos”, del ingles Redundant Array of InexpensiveDisks, y hace referencia a un sistema de almacenamiento que usa multiples discos duros entre los quedistribuye o replica los datos.

9Para una discusion sobre los tipos de memoria y las funciones existentes para solicitarla acuda al punto3.3.

49


1. rbd make request fail: esta funcion retorna con error todas las peticiones que lellegan. Su proposito es simple: sirve de contencion hasta que se definan los soportesa los que el dispositivo despachara las peticiones.

2. mapeo make request: esta es la funcion principal encargada de trasladar las peticio-nes que le lleguen al dispositivo virtual. Decidira, segun el tipo de peticion (lecturao escritura) y los sectores accedidos, a que dispositivo y a que sector debe redirigirla peticion. Esta funcion se explicara mas detalladamente en el punto 4.3.2.

Finalmente, se incluye el codigo del proyecto (fragmento 4.13) que hace uso de loexplicado en este punto.

Listado 4.13: Creacion de una cola de dispositivo./∗ Crea un d i s p o s i t i v o con e l ”minor” i n d i c a d o ∗ /s t a t i c s t r u c t r o l l b a c k d e v ∗ r b d c r e a t e ( i n t 3 2 t i ){. . .

/∗ I n i c i a l i z a r l a c o l a ∗ /dev−>c o l a = b l k a l l o c q u e u e (GFP KERNEL) ;i f ( dev−>c o l a == NULL) {

p r i n t k (KERN ERR ” rbd : u n a b l e t o a l l o c a t e queue .\ n ” ) ;r e t = −ENOMEM;go to o u t f r e e ;

}b l k q u e u e m a k e r e q u e s t ( dev−>co la , r b d m a k e r e q u e s t f a i l ) ;dev−>co la−>q u e u e d a t a = dev ;

. . .}

/∗ E l i m i n a t o d o s l o s d i s p o s i t i v o s ∗ /s t a t i c vo id rbd remove ( vo id ){. . .

b l k p u t q u e u e ( dev−>c o l a ) ;. . .}

4.2.5. Control de entrada y salida

4.2.5.1. Introduccion

Ademas de las operaciones clasicas de lectura y escritura sobre un dispositivo, los dis-positivos suelen ofrecer al usuario una interfaz de control del hardware que administran.En nuestro caso, aunque el dispositivo sea virtual, es necesario poder comunicarse con elpara poder indicarle multitud de cosas: que dispositivo usara para las lecturas y cual para

50


las escrituras, poner en marcha o detener el dispositivo, solicitar informacion del estadodel mismo, etc.

Este control se realiza mediante una interfaz denominada ioctl10 y permite enviar unoscomandos previamente definidos al dispositivo. Para ello, basta con enviar mediante lafuncion ioctl el comando deseado al dispositivo que corresponda, el cual estara repre-sentado por un descriptor de fichero. Adicionalmente, se puede pasar una variable quecontenga datos necesarios para completar el comando o, por el contrario, lo usara el con-trolador para devolver algun tipo de informacion al usuario.

Listado 4.14: Pagina ioctl del manual del programador de Linux# i n c l u d e <s y s / i o c t l . h>

i n t i o c t l ( i n t d , i n t r e q u e s t , . . . ) ;

Desde el punto de vista del nucleo, y mas concretamente del controlador que tratara lapeticion ioctl, la funcion encargada de analizar y actuar adecuadamente ante la peticiontiene que calcar la definicion del prototipo que se indica en el listado 4.15. Esta funcionretornara cero si todo ha ido correctamente, o error en caso contrario. El estandar POSIX11

obliga a devolver el codigo de error -ENOTTY si el comando recibido es inapropiado.

Listado 4.15: Funcion ioctl.# i n c l u d e < l i n u x / f s . h>

i n t (∗ i o c t l ) ( s t r u c t i n o d e ∗ , s t r u c t f i l e ∗ , uns igned , u n s i g n e dlong ) ;

El nucleo sabe a que funcion tiene que pasarle la peticion, puesto que, al registrar eldispositivo, ya se le indico, dentro de la estructura block device operations, mediante elcampo ioctl. En nuestro caso la funcion indicada fue rollback ioctl.

Solo se explicara la parte de ioctl relativa al nucleo. La parte correspondiente al espa-cio del usuario sera explicada brevemente en el apendice A.3.

4.2.5.2. Comandos

Para nuestro dispositivo se definieron ocho posibles comandos (ver listado 4.16) quepermitiesen un control absoluto del mismo:

Version: informa de la version del controlador. El controlador devolvera a la aplicacionun entero que identifica la version.

Info: aporta informacion sobre el estado de un dispositivo. Esa informacion incluye datoscomo que dispositivo esta usando para las lecturas y cual para las escrituras, la

10Acronimo de input/output control o “control de entrada y salida”.11Acronimo de Portable Operating System Interface (la X viene de UNIX como sena de identidad del

API) que engloba a una familia de estandares de llamadas al SO que persigue generalizar las interfaces delos SO para que una misma aplicacion pueda ejecutarse en distintas plataformas.

51


memoria ocupada en el nucleo por ahora, el maximo previsto, el numero de bloquesdisponibles, etc. Toda esta informacion es proporcionada por el controlador pormedio de una estructura creada ad hoc denominada rbd info ioctl.

Create: se encarga de indicar al dispositivo que dispositivo usara para las lecturas y cualpara las escrituras. Para tal fin usa una estructura denominada rbd create ioctl.

Delete: indica al controlador que libere los dispositivos adquiridos por medio del coman-do Create.

Run: indica al dispositivo que empiece a funcionar. Hasta que no se envıe este comando,el dispositivo estara detenido. Recibe un entero que es un porcentaje mınimo debloques libres que debe haber. Si se traspasa ese lımite, el controlador avisara alusuario de que empieza a haber pocos bloques libres.

Stop: detiene el dispositivo indicado y, por tanto, las operaciones sobre el. Es el pasoprevio a eliminarlo mediante el comando Delete. No necesita de ningun parametroadicional.

Reset: le indica al dispositivo que ejecute el comando Stop seguido de un Run. Ası seconsigue reiniciar el dispositivo rapidamente. Como este comando es un alias parala operacion conjunta representada por Stop y Run, acepta el parametro de esteultimo.

Sync: realiza una sincronizacion de contenido entre el dispositivo de escrituras y el delecturas, actualizando el contenido de este ultimo con las modificaciones almace-nadas en el primero. Tampoco necesita de ningun parametro adicional.

Listado 4.16: Comandos ioctl definidos en el fichero map.h./∗ Comandos IOCTL ∗ /# d e f i n e RBD IOC MAGIC ’ z ’# d e f i n e RBD VERSION IOR ( RBD IOC MAGIC , 0x01 , u i n t 3 2 t )# d e f i n e RBD INFO IOR ( RBD IOC MAGIC , 0x02 , s t r u c t

r b d i n f o i o c t l )# d e f i n e RBD CREATE IOW ( RBD IOC MAGIC , 0x03 , s t r u c t

r b d c r e a t e i o c t l )# d e f i n e RBD DELETE IO ( RBD IOC MAGIC , 0x04 )# d e f i n e RBD RESET IOW ( RBD IOC MAGIC , 0x05 , u i n t 8 t )# d e f i n e RBD RUN IOW ( RBD IOC MAGIC , 0x06 , u i n t 8 t )# d e f i n e RBD STOP IO ( RBD IOC MAGIC , 0x07 )# d e f i n e RBD SYNC IO ( RBD IOC MAGIC , 0x08 )# d e f i n e RBD IOC MAXNR 8

Aunque podrıa parecer normal definir los comandos como una secuencia de numeros,por ejemplo empezando en uno, esto no es lo deseable. El motivo es evitar mandar uncomando por error a un dispositivo que no le corresponde y que, a pesar de ello, le afecte,

52


puesto que no son unicos. Ası que lo mejor es intentar garantizar, en la medida de loposible, la unicidad de los distintos comandos.

La solucion pasa por crear los comandos ioctl mediante la concatenacion de distintoscampos:

type: identifica al dispositivo, por tanto, cada tipo de dispositivo deberıa tener un numerounico asignado. Hay un listado de numeros asignados que se puede consultar en elfichero Documentation/ioctl-number.txt de Linux.

number: es un cardinal que discrimina entre varios comandos del mismo tipo de dispo-sitivo.

direction: indica la direccion de la transferencia de datos, siempre desde el punto de vistade la aplicacion. Hay tres posibilidades:

IOC NONE: no hay transferencia de datos.

IOC READ: se transfieren datos del controlador a la aplicacion.

IOC WRITE: se transfieren datos de la aplicacion al controlador.

size: informa del tamano de los datos que se transmiten entre la aplicacion y el controla-dor.

Como siempre, en aras de facilitar el desarrollo, Linux ofrece una serie de macros quese encargan de dirimir con los distintos campos. Las macros disponibles pueden verse acontinuacion:

Listado 4.17: Macros para la creacion de ioctl.# i n c l u d e < l i n u x / i o c t l . h>

IO ( type , number )IOR ( type , number , s i z e )IOW ( type , number , s i z e )IOWR ( type , number , s i z e )

IO: define un ioctl sin transferencia de datos.

IOR: define un ioctl que lee datos del controlador.

IOW: define un ioctl que envıa datos al controlador.

IOWR: define un ioctl que envıa y lee datos del controlador.

53


4.2.5.3. Tratamiento

Ya se han definido los comandos ioctl que aceptara el dispositivo. El siguiente pasoes tratarlos dentro del controlador para que, dependiendo del comando, se obre en conse-cuencia.

La mayorıa de los comandos requieren una transferencia de datos entre el espacio dememoria del usuario y el propio del nucleo. Estas condiciones imponen el uso de unaserie de funciones adicionales:

access ok comprueba si el parametro, un puntero, apunta a una posicion de memoriadentro del mapa de memoria del proceso que es accesible desde el nucleo.

Una vez se sabe que es accesible el puntero y se quiere leer del mismo la in-formacion apuntada, debe usarse alguna de las siguientes funciones: get user ocopy from user. Las dos copian a espacio del nucleo el contenido al que apunta elpuntero, pero con una pequena diferencia: get user esta especializada en tipos dedatos clasicos (entero, byte, etc), mientras que copy from user se usa para estructu-ras o similares.

Del mismo modo que hay unas funciones para leer del espacio del usuario, hayotras para escribir. Son put user y copy to user y su utilizacion es semejante a lasde lectura.

Listado 4.18: Acceso a memoria del espacio del usuario.# i n c l u d e <asm / u a c c e s s . h>

boo l a c c e s s o k ( type , addr , s i z e ) ;

vo id g e t u s e r ( x , p t r ) ;

vo id p u t u s e r ( x , p t r ) ;

Como ya se comento en la introduccion, la funcion rollback ioctl es la encargada degestionar las peticiones enviadas al dispositivo y ahora se explicara que hace realmentecon cada peticion:

Info: recaba toda la informacion que necesita y la vuelca en la estructura rbd info ioctl.

Listado 4.19: Ioctl RBD INFO.c a s e RBD INFO : /∗ Es tado d e l d i s p o s i t i v o ∗ /

/∗ Comprobar e l da to y r e a l i z a r e l IOCTL ∗ /i f ( ! a c c e s s o k ( VERIFY WRITE , ( vo id u s e r ∗ ) arg ,

IOC SIZE ( cmd ) ) )r e t u r n −EFAULT ;

/∗ R e a l i z a r e l IOCTL y c o p i a r e l da to a l e s p a c i o deu s u a r i o ∗ /

54


r o l l b a c k i o c t l i n f o ( c l a v e , &i n f o ) ;p t r i n f o = ( s t r u c t r b d i n f o i o c t l u s e r ∗ ) a r g ;i f ( c o p y t o u s e r ( p t r i n f o , &i n f o , s i z e o f ( i n f o ) ) )

r e t u r n −EFAULT ;r e t u r n 0 ;

Create: toma nota de los datos de los dispositivos que usar descritos mediante la estruc-tura rbd create ioctl.

Listado 4.20: Ioctl RBD CREATE.c a s e RBD CREATE : /∗ Crear d i s p o s i t i v o ∗ /

/∗ C o n t r o l de ac ce s o ∗ /i f ( ! c a p a b l e ( CAP SYS ADMIN ) )

r e t u r n −EACCES ;

/∗ Comprobar e l da to y r e a l i z a r e l IOCTL ∗ /i f ( ! a c c e s s o k ( VERIFY READ , ( vo id u s e r ∗ ) arg ,


p t r c r e a t e = ( s t r u c t r b d c r e a t e i o c t l u s e r ∗ ) a r g ;i f ( c o p y f r o m u s e r (& c r e a t e , p t r c r e a t e , s i z e o f

( c r e a t e ) ) )r e t u r n −EFAULT ;

r e t u r n r o l l b a c k i o c t l c r e a t e ( c l a v e , c r e a t e ) ;

Delete: elimina el dispositivo indicado.

Listado 4.21: Ioctl RBD DELETE.c a s e RBD DELETE : /∗ E l i m i n a r d i s p o s i t i v o ∗ /



/∗ R e a l i z a r e l IOCTL ∗ /r e t u r n r o l l b a c k i o c t l d e l e t e ( c l a v e ) ;

Run: pone en marcha el dispositivo usando como umbral de bloques libres el valor indi-cado por arg.

55


Listado 4.22: Ioctl RBD RUN.c a s e RBD RUN: /∗ I n i c i a r d i s p o s i t i v o ∗ /



/∗ R e a l i z a r e l IOCTL ∗ /r e t u r n r o l l b a c k i o c t l r u n ( c l a v e , ( u i n t 8 t ) a r g ) ;

Stop: detiene el dispositivo indicado.

Listado 4.23: Ioctl RBD STOP.c a s e RBD STOP : /∗ Detener d i s p o s i t i v o ∗ /



/∗ R e a l i z a r e l IOCTL ∗ /r e t u r n r o l l b a c k i o c t l s t o p ( c l a v e ) ;

Reset: este comando se transforma en los comandos Stop y Run ejecutados uno detras deotro.

Listado 4.24: Ioctl RBD RESET.c a s e RBD RESET : /∗ R e i n i c i a r d i s p o s i t i v o ∗ /



/∗ R e a l i z a r e l IOCTL ∗ /r e t u r n r o l l b a c k i o c t l r e s e t ( c l a v e , ( u i n t 8 t ) a r g ) ;

Sync: inicia la sincronizacion del dispositivo indicado.

Listado 4.25: Ioctl RBD SYNC.c a s e RBD SYNC : /∗ A c t u a l i z a r e l d i s p o s i t i v o

o r i g i n a l ∗ //∗ C o n t r o l de ac ce s o ∗ /i f ( ! c a p a b l e ( CAP SYS ADMIN ) )


/∗ R e a l i z a r e l IOCTL ∗ /r e t u r n r o l l b a c k i o c t l s y n c ( c l a v e ) ;

56


Version: se limita a copiar la version en la posicion apuntada por el parametro arg.

Listado 4.26: Ioctl RBD VERSION.c a s e RBD VERSION : /∗ V e r s i o n d e l d r i v e r ∗ /

/∗ Copiar e l da to a l e s p a c i o de u s u a r i o ∗ /i f ( ! a c c e s s o k ( VERIFY WRITE , ( vo id u s e r ∗ ) arg ,


r e t u r n p u t u s e r (VERSION RBD , ( u i n t 3 2 t u s e r ∗ )a r g ) ;

En casi todos los comandos se implementa un chequeo adicional de privilegios, yaque, de no ser ası, cualquier usuario podrıa realizar cambios en el dispositivo. Los uni-cos comandos que un usuario normal deberıa poder invocar son los informativos (Info yVersion). Esta proteccion se consigue comprobando, mediante la funcion capable, si elusuario que envıa el comando tiene permisos de administrador (CAP SYS ADMIN).

Listado 4.27: Comprobacion de permisos.# i n c l u d e < l i n u x / c a p a b i l i t y . h>i n t c a p a b l e ( i n t cap ) ;

# d e f i n e CAP SYS ADMIN 21

4.2.6. Miscelanea

En este apartado se explicaran ciertas partes del desarrollo que, aunque necesariaspara terminar de comentar esta etapa del desarrollo, apenas guardan relacion entre ellas.

4.2.6.1. Estructuras

Como se comento en el apartado sobre modulos (punto 4.2.1), el controlador puederecibir un parametro durante la carga del modulo: este parametro indicaba cuantas ins-tancias del dispositivo deberıan crearse. Puesto que el numero de instancias nunca es fijoentre una carga del modulo y otra, es necesario poder gestionar estas instancias dentro delcodigo: concretamente habra una estructura del tipo rollback dev (ver listado 4.28) porcada instancia.

Para este tipo de problematica suelen emplearse listas enlazadas donde cada elementode la lista es una instancia de la estructura deseada y, ademas, apunta al siguiente ele-mento. De hecho, Linux tambien provee de listas doblemente enlazadas mediante un tipoespecial struct list head y sus funciones asociadas.

La explicacion a este soporte viene dada porque es un tipo muy comun en los desa-rrollos software y existıan muchas implementaciones en el nucleo, propias de cada de-sarrollador, utilizadas en sus contribuciones a Linux. En un determinado momento, los

57


desarrolladores de Linux acordaron crear un tipo estandar y las funciones necesarias pa-ra utilizarlo, para ası unificar las distintas implementaciones, siendo ası mucho mas facilcorregir fallos y evitando codigo redundante dentro de Linux.

Aunque el uso de una lista enlazada parece una solucion correcta, no lo es completa-mente, al menos no con este problema. Puesto que se crean todas las estructuras asociadasa sus instancias correspondientes durante la carga del modulo y se eliminan conjuntamen-te, sin haber variaciones en su numero durante todo su uso, es mas simple y rapido usarun vector de estructuras que las contenga.

Este vector se crea durante la carga y es destruido al descargar el modulo de memoria.Para acceder a cada instancia basta indexar con su minor en el vector y ası se obtendra suestructura rollback dev asociada.

Listado 4.28: Estructura con informacion de la instancia del dispositivo./∗ I n f o r m a c i o n s o b r e e l d i s p o s i t i v o ∗ /s t r u c t r o l l b a c k d e v {

d e v t c l a v e ;enum r b d i n i t i n i c i a d o ;i n t 8 t o r i g i n a l s t r [MAX LEN ] ;s t r u c t b l o c k d e v i c e ∗ o r i g i n a l ;i n t 8 t e s c r i t u r a s t r [MAX LEN ] ;s t r u c t b l o c k d e v i c e ∗ e s c r i t u r a ;s t r u c t g e n d i s k ∗ d i s c o ;s t r u c t r e q u e s t q u e u e ∗ c o l a ;s p i n l o c k t l o c k ;a t o m i c t u s u a r i o s ;u i n t 3 2 t s e c t o r e s b l o q u e ;s e c t o r 3 2 t s e c t o r 0 ;s t r u c t m a p a i n f o ∗ m a p a i n f o ;

} ;

clave: identificador que sirve para distinguir entre varias instancias del dispositivo.

iniciado: indica el estado actual de la instancia: inicial (sin CREATE), creado (justo des-pues de CREATE), listo (despues de RUN) o sincronizando (mientras se ejecuta elSYNC). La transicion entre los distintos estados se puede ver en la figura 4.1.

Mediante el comando RESET se lanzarıa un comando STOP y luego un RUN. Cuan-do se envıa el comando SYNC, el estado cambia y no retorna a LISTO hasta que noha terminado la sincronizacion de contenido. No hay comando ninguno para hacerlevolver, de ahı el sımbolo *.

original str: cadena que representa al dispositivo del que solo se leeran datos.

original: apunta al dispositivo una vez abierto.

escritura str: cadena que representa al dispositivo en el que se realizaran escriturasademas de lecturas sobre los datos escritos.

58


Figura 4.1: Transicion entre estados del controlador.

escritura: apunta al dispositivo una vez abierto.

disco: representa la instancia del dispositivo virtual desde el punto de vista del nucleo, esdecir, como un disco.

cola: cola encargada de almacenar las peticiones que se le envıen a esta instancia.

lock: spin lock encargado de no permitir modificaciones concurrentes a la estructura.

usuarios: numero de veces que ha sido abierto el volumen virtual.

sectores bloque: puesto que el volumen virtual ha de contener los mismos sectores queel de lecturas u original, es necesario que tambien sepa el tamano en sectores delbloque del dispositivo, puesto que el tamano de las peticiones que le lleguen siempresera multiplo de este valor. Es mas, normalmente estaran alineadas de forma queempiecen en un bloque.

sector0: suele haber una peticion que no esta alineada ni en el origen ni en el tamano debloque: la peticion inicial. Cuando el codigo del sistema de ficheros monta la parti-cion no sabe el tamano de bloque hasta que no lo lee, normalmente del superbloque.Por seguridad, lanzara una peticion de lectura conservadora, que puede no encajarcon el tamano de bloque de la particion, y luego, una vez sepa el tamano correcto,es cuando procedera a realizar las peticiones correctamente. Para decirle al contro-lador que permita pasar esta peticion inicial “desalineada” se le indica el sector delque puede leerse sin tener en cuenta las restricciones del tamano de bloque.

mapa info: almacena toda la informacion utilizada en la logica de mapeo.

Puesto que es durante la inicializacion del modulo cuando se solicitan tantas instanciasde esta estructura como dispositivos se quieren crear, es posible pedir la memoria sin teneren cuenta ningun tipo de restricciones: GFP KERNEL.

59


4.3. Logica del mapeo

4.3.1. Tratamiento clasico de una peticion E/SComo se comento anteriormente, cuando un proceso quiere leer el contenido de un

fichero, comunica su peticion al sistema de ficheros encargado del dispositivo donde sehalla el fichero. El sistema de ficheros la traducira a una peticion de acceso a determi-nados bloques del dispositivo, siempre que la informacion no estuviera ya en cache. Estapeticion contendra, entre otras cosas, informacion del sector al que ha de accederse dentrodel dispositivo, el numero de sectores a los que acceder, un campo que identifique el tipode operacion como lectura, una coleccion de paginas de memoria donde alojar el conte-nido leıdo, etc. Todo estos datos se encuentran dentro de una estructura denominada BIOo Block Input/Output (ver listado 4.30).

Este BIO es creado y rellenado adecuadamente por el subsistema que necesita acce-der al dispositivo, por ejemplo el sistema de ficheros Ext2, y es enviado a la cola deldispositivo. Mientras esta en la cola, el planificador de E/S puede decidir combinar pe-ticiones o reordenar la cola para optimizar el rendimiento del dispositivo. Cada vez queel dispositivo esta desocupado, el controlador lee una peticion BIO de la cola y procedea satisfacerla. Una vez lo ha hecho, avisa al subsistema que envio la peticion de que suoperacion ha sido completada para que pueda seguir como crea conveniente; mientras, eldispositivo toma otra peticion de la cola e igualmente procede a tratarla.

Para satisfacer una peticion BIO, el controlador del dispositivo, una vez ha tomadouna de su cola, hace lo siguiente:

1. Toma nota del sector inicial y del tipo de operacion.

2. Dependiendo del tipo de operacion:

a) Si es una lectura: se iran leyendo del soporte los sectores, todos ellos conse-cutivos, y se iran almacenando en los bloques contenidos en los segmentosindicados por el BIO.

b) Si es una escritura: se iran leyendo de los segmentos del BIO los bloques amedida que se quiera escribir su contenido en los sectores del dispositivo.

3. Una vez se termine la operacion, haya sido completada satisfactoriamente o hayafallado en algun punto, el dispositivo le hara notar la situacion al emisor del BIO.

Se sobreentiende que, para leer o escribir en el dispositivo, el controlador tendra queenviar los comandos adecuados al hardware.

La unidad mınima de transferencia de un dispositivo es el sector de 512 bytes, deforma que las peticiones deben indicar la cantidad de sectores que requieren. Pero elnucleo impone que las transferencias sean de mas sectores, concretamente del tamanode bloque del sistema de ficheros del dispositivo, porque es probable que los siguientesdatos que se necesiten sean adyacentes a los actuales. Este bloque agrupa un multiplo desectores que debe cumplir las siguientes condiciones:

60

4.3 Logica del mapeo

Figura 4.2: Bloques, segmentos y paginas.

Ser una potencia de dos.

Debe ser inferior o igual al tamano de pagina, normalmente 4096 bytes.

Debe ser multiplo del tamano de sector: 512 bytes.

Por tanto, los tamanos de bloque permitidos son 512, 1024, 2048 y 4096. El tamano debloque depende del sistema de ficheros del dispositivo. De hecho, si hay varios sistemasde ficheros en distintas particiones de un dispositivo, cada particion podrıa usar un tamanode bloque distinto para las transferencias. En el caso de que se haga la lectura de datos enbruto de un dispositivo, sin pasar por un sistema de ficheros, se toma el mayor valor: 4KiB, el tamano de pagina. Ademas, los bloques adyacentes dentro de un pagina, a la horade participar en una transferencia, son agrupados en segmentos y estos no pueden abarcarmas alla de su pagina.

En la figura 4.2 se puede ver una pagina de memoria que contiene:

1. Tres bloques consecutivos, cada uno de 1024 bytes, agrupados en un segmento.

2. Un bloque de 1024 bytes no consecutivo con los anteriores y que es contenido porun segmento diferente.

Listado 4.29: Estructura de un bio vec.# i n c l u d e < l i n u x / b i o . h>

s t r u c t b i o v e c {s t r u c t page ∗ bv page ;u n s i g n e d i n t b v l e n ;

61


u n s i g n e d i n t b v o f f s e t ;} ;

bv page: pagina de memoria asociada.

bv len: longitud del segmento dentro de la pagina.

bv offset: desplazamiento dentro de la pagina donde comienza el segmento.

La peticion BIO apunta a un vector de estructuras bio vec (ver listado 4.29) dondecada estructura representa un segmento dentro de una pagina que debe ser utilizado paraalmacenar o leer los bloques implicados en la transferencia. El segmento esta delimitadopor los campos bv offset (origen) y bv len (longitud) dentro de cada pagina. Sumando lostamanos de cada segmento de cada pagina se obtendra un valor igual al tamano en bytesde los sectores a transferir.

Figura 4.3: Relacion de los distintos BIO con sus segmentos y bloques.

Para que sea mas facil entender como se crean los BIO y su relacion con los bloques,segmentos y paginas se mostrara un ejemplo en el que se necesita leer 9000 bytes de unfichero F.

62


1. A traves de la llamada al sistema sys read llega una peticion de lectura de los pri-meros 9000 bytes del fichero F.

2. Linux considera que un fichero esta compuesto por paginas, de forma que, ante unapeticion de acceso a un intervalo de un fichero, traduce esa peticion al conjuntode paginas que deberıan almacenar ese contenido. El tamano de pagina es de 4096bytes, ası que la lectura requerira de tres paginas: 4096+4096+808 = 9000 bytes.Al ser los primeros 9000 bytes, las paginas necesarias seran las tres primeras delfichero.

3. El sistema de ficheros consulta en la cache de paginas, mediante el identificador delfichero, si estan disponibles esas tres paginas de una lectura o acceso anterior. Sesupondra que no se encuentran en la cache las paginas solicitadas.

4. El sistema de ficheros necesita obtener esas paginas, ası que debera acceder al dis-positivo de bloques subyacente. Por tanto, para rellenar adecuadamente cada pagi-na, debera leer los bloques que almacenan esos 9000 bytes y almacenarlos en lastres paginas. Suponiendo un tamano de bloque de 1024 bytes, el SF elabora unalista con los bloques de datos implicados en la operacion consultando los primerosdoce punteros de datos del i-nodo: 80, 81, 82, 83, 84, 100, 101, 70, 102, 110, 111,112. Aunque solo son necesarios nueve bloques, se leen doce por la proximidadespacial12 y, ademas, ası termina de rellenar la ultima pagina con datos.

5. Para poder optimizar el rendimiento, Linux agrupa los accesos de forma que cadaBIO trate con sectores colindantes. Ası, se formarıan cuatro peticiones BIO:

a) BIO 1: sector 70.

b) BIO 2: sectores 80 al 84.

c) BIO 3: sectores 100 al 102.

d) BIO 4: sectores 110 al 112.

6. Cada bloque que va a ser leıdo tiene un lugar asignado dentro de alguna de lastres paginas. Por tanto, cada BIO debe tener una lista de estructuras bio vec quedescriba los segmentos implicados. Los segmentos agrupan, dentro de una mismapagina, bloques que vayan a ser tratados por la misma peticion BIO. Si el hardwaretiene soporte para transferencias DMA13 scatter-gather14, cada BIO podra hacerreferencia a distintos segmentos; si no, cada BIO debera tratar, de uno en uno, lossegmentos.

12Es bastante probable que si se ha accedido a un bloque n, alguno de los siguientes bloques en seraccedido sea n+1.

13El acceso directo a memoria, del ingles Direct Memory Access, es un tipo de transferencia entre undispositivo y la memoria del sistema en la cual no es necesaria la intervencion del procesador.

14En las transferencias clasicas de DMA, las posiciones de memoria accedidas deben ser consecutivas.Si el hardware tiene soporte para scatter-gather, esas posiciones de memoria pueden ser discontinuas.

63


Por tanto, los cuatro BIO quedarıan tal y como se puede ver en la figura 4.3:

a) BIO 1: un segmento que engloba el bloque 70 en la pagina dos.

b) BIO 2: un segmento que engloba todos los bloques en la pagina uno y otrosegmento que engloba el bloque 84 en la pagina dos. La pagina uno juntocon el principio de la pagina dos no podrıan formar un segmento unico por larestriccion de que los segmentos deben estar contenidos por las paginas.

c) BIO 3: un segmento que engloba los bloques 100 y 101 de la pagina dos yotro segmento que engloba el bloque 102 de la pagina tres. Puesto que haybloques dispersos en dos paginas no es posible tratar la peticion como si fueraun unico segmento.

d) BIO 4: un segmento que engloba los bloques 110, 111 y 112 de la pagina tres.

A continuacion, se explicara la base de las peticiones: la estructura BIO (solo loscampos importantes).

Listado 4.30: Estructura BIO.# i n c l u d e < l i n u x / b i o . h>

s t r u c t b i o {s e c t o r t b i s e c t o r ;s t r u c t b l o c k d e v i c e ∗ b i b d e v ;u n s i g n e d long b i f l a g s ;u n s i g n e d long b i r w ;u n s i g n e d s h o r t b i v c n t ;u n s i g n e d s h o r t b i i d x ;u n s i g n e d i n t b i s i z e ;s t r u c t b i o v e c ∗ b i i o v e c ;b i o e n d i o t ∗ b i e n d i o ;a t o m i c t b i c n t ;vo id ∗ b i p r i v a t e ;b i o d e s t r u c t o r t ∗ b i d e s t r u c t o r ;

} ;

bi sector: sector desde el que dara comienzo la transferencia.

bi bdev: dispositivo del que se leera o escribira.

bi flags: almacena el estado de la peticion.

bi rw: tipo de operacion que realizar: lectura o escritura.

bi vcnt: numero de segmentos del campo bi io vec.

bi idx: ındice dentro del vector de segmentos. Puesto que las peticiones pueden no tra-tarse enteramente mediante una sola pasada, se anotara en este campo cual es elsiguiente segmento al que acceder. En el siguiente intento para completar la peti-cion se partira desde este segmento.

64


bi size: numero de bytes por transferir aun. Al igual que con el campo anterior, si nose ha completado la peticion entonces este campo indicara los bytes restantes. Unavez sea cero, se dara por satisfecha la peticion, siempre que no se produzca un errorantes.

bi io vec: almacena un vector de estructuras bio vec donde cada una de ellas ofrece in-formacion de un segmento que debera ser utilizado para realizar la transferenciapedida.

bi end io: puntero a la funcion encargada de avisar al emisor de la peticion BIO de queesta ha sido completada, sea con error o no.

bi cnt: contador de referencias de la estructura. Evita que se elimine o libere la estructuramientras esta en uso.

bi private: campo que utilizara el emisor de la peticion como crea conveniente.

bi destructor: puntero a la funcion encargada de liberar la memoria usada por la estruc-tura BIO.

Es importante recalcar, una vez mas, por que no tiene sentido una cola real en eldispositivo que esta siendo desarrollado: el dispositivo es virtual y no sirve de nada. Tratarde alguna forma las peticiones que a el llegan es desperdiciar tiempo de procesador ymemoria. Actua como una estacion de paso donde tener constancia de las peticiones ypoder acceder a ellas para su posterior tratamiento.

4.3.2. Tratamiento de la peticion de E/S por parte de la solucionLa parte de tratamiento y manipulacion de la peticion BIO se da una vez ha llega-

do a la cola del dispositivo. Este es avisado mediante la ejecucion de la funcion ma-peo map request, como se vio al asociar esa funcion a la cola en el punto 4.2.4.

Para poder discernir que bloques se encuentran en el dispositivo de lecturas (DL) ycuales en el de escrituras (DE), se utiliza un vector que hara las labores de mapa. El mapao vector contiene posiciones de bloque, de forma que, al indexar un numero de bloque, seobtiene uno de los siguientes valores:

Una constante predefinida que indica que no se ha mapeado ese bloque y que de-nominaremos NO MAPEADO. Obtener ese valor significa que ese mismo numerode bloque debe buscarse en DL.

Un bloque, situado en el dispositivo de escrituras, donde se almacena realmenteel bloque solicitado. En este caso el bloque dado, correspondiente al dispositivovirtual, debe sustituirse por el bloque obtenido al indexar y redirigir la operacionsobre ese bloque a DE.

65


Por tanto, el tamano del vector es el tamano en bloques del dispositivo virtual; tamanoque es el mismo que el de DL, puesto que el tamano del dispositivo virtual se tomo de DLdurante la inicializacion del dispositivo.

Cuando llegue una peticion, se anotaran los bloques implicados en la transferencia yse indexaran sus posiciones en el mapa, obteniendo las posiciones correspondientes enDE o DL. Los bloques implicados en la transferencia se pueden deducir mediante:

el sector inicial indicado por bi sector mas

el numero de bloques por transferir, obtenidos al dividir el volumen de bytes indi-cado por bi size entre el tamano de bloque.

Al aplicar esa region sobre el mapa se obtienen las “subzonas”. Cada subzona repre-senta un conjunto de bloques que pueden ser procesados como una peticion BIO. Si seobtiene una unica subzona, se puede reaprovechar la peticion BIO original, de forma que,retocando los campos necesarios, se procese correctamente.

Si la peticion BIO original da lugar a varias subzonas, sera necesario fabricar peticio-nes BIO propias, donde cada una de ellas se encargue de procesar cada subzona. Una vezterminen esas peticiones o miniBIO15 se dara por satisfecha la peticion BIO original y seavisara al emisor de la misma.

Una subzona es detectada, cuando, al traducir mediante el mapa los bloques implica-dos en la transferencia, se detectan las siguientes condiciones:

La subzona, hasta el momento, se halla compuesta de bloques sin mapear, es decir,su valor es NO MAPEADO, y el siguiente bloque del vector no tiene ese valor.

Figura 4.4: Ejemplo de subzona: bloques NO MAPEADO y bloques mapeados.

La subzona, hasta el momento, se compone de bloques cuyos valores dentro del ma-pa son consecutivos y llegan a dar con un bloque no consecutivo o NO MAPEADO.

15Un miniBIO es un BIO normal pero que se encarga de satisfacer una porcion del BIO original repre-sentada por una subzona.

66


Figura 4.5: Ejemplo de subzona: bloques mapeados consecutivos y no consecutivos.

Habra veces en que la peticion vaya a un solo dispositivo, el de escrituras, pero, aunası, deba ser fragmentada. La razon mas probable es que los bloques implicados en laoperacion no sean consecutivos en el dispositivo destino. Por ejemplo:

1. Recien inicializado el dispositivo virtual, se deciden leer los bloques 0 y 8 del mis-mo, lo que hara que se lean del dispositivo de lecturas.

2. Una vez leıdos, son modificados y escritos a disco. Al hacerlo, estas escrituras seredirigiran a los bloques 0 y 1 del dispositivo de escrituras, puesto que son losprimeros bloques libres disponibles.

3. Se decide leer el bloque 2 del dispositivo virtual. Esta lectura se transforma en unalectura del mismo bloque, pero del dispositivo de lecturas.

4. Despues de leıdo, es modificado y escrito a disco. El bloque que ocupara sera elsiguiente disponible del dispositivo de escrituras: el bloque 2.

5. Si se lanza una operacion de lectura de los bloques 0 y 1, esta sera dirigida hacia eldispositivo de escrituras y fragmentada, puesto que, aunque son consecutivas en eldispositivo virtual (0 y 1), no lo son en el de escrituras (0 y 2), dando lugar a dossubzonas que seran tratadas mediante dos miniBIO.

Una vez explicado el funcionamiento de las subzonas y como se producen, se mos-trara a continuacion como se trata la peticion una vez llega a la cola del dispositivo:

1. Se calculan las subzonas implicadas mediante el mapa y los campos de la peticionBIO.

2. Dependiendo del tipo de operacion:

a) Se trata de una lectura:

1) La lectura comienza en un bloque no modificado y abarca bloques nomodificados (una unica subzona): se envıa la peticion, sin modificar, aldispositivo de lecturas.

2) La lectura se realiza sobre una subzona modificada: se envıa la peticion aldispositivo de escrituras, ajustando el sector de inicio para que sea correc-to.

67


3) La lectura se realiza sobre varias subzonas: unas no estan mapeadas yotras sı. El procedimiento consiste en fragmentar la peticion BIO en tan-tos otros miniBIO como subzonas haya. El sector de inicio, la cantidad debloques que transferir y demas valores de la peticion son ajustados paracada una de las peticiones. Se enviaran unos miniBIO al dispositivo delecturas y otros al de escrituras.

b) Se trata de una escritura:

1) La escritura es sobre un bloque no modificado y abarca una sola subzo-na. Se usan los primeros bloques libres del dispositivo de escrituras paraalmacenar el contenido de la peticion, por lo que la peticion es redirigi-da a este dispositivo. Ademas, se actualiza el vector de mapeo o mapade forma que subsiguientes accesos a los mismos bloques del dispositivovirtual redirijan a los mismos bloques del dispositivo de escrituras.

2) La escritura es sobre una unica subzona ya mapeada: se modifica la peti-cion BIO para que acceda al dispositivo de escrituras y se corrige el sectorinicial con el valor correcto obtenido al indexar en el mapa.

3) La escritura es sobre varias subzonas: unas no estan mapeadas y otras sı.Al igual que en la lectura, es necesario fragmentar la peticion medianteminiBIO en tantas partes como subzonas haya. Las subzonas ya mapea-das tomaran el sector inicial correspondiente del mapa y seran enviadas aldispositivo de escrituras. Las no mapeadas tendran que localizar bloqueslibres y ser redirigidas a ellos ademas de actualizar sus posiciones en elmapa.

Enviar una peticion a un dispositivo u otro supone ajustar el campo bi bdev para quehaga referencia al dispositivo correspondiente. Para aportar mas claridad de todo el pro-ceso se mostrara un ejemplo:

1. El dispositivo virtual acaba de crearse. El dispositivo DL se encargara de las lec-turas, mientras que DE se hara cargo de las escrituras y de las lecturas sobre datosmodificados.

2. Llega una peticion de lectura del bloque 0. Se comprueba al indexar el nume-ro de bloque en el mapa que este bloque no ha sido mapeado, es decir, el va-lor devuelto es NO MAPEADO. Se envıa la peticion, sin cambios, mismo bloquey cantidad de bloques a leer, a DL. Usando una notacion particular se dira que:[0]:NO MAPEADO16.

3. Llega una peticion de escritura del bloque 0. Se comprueba igualmente y se observaque no ha sido mapeado. Por tanto, al ser una escritura y no tener bloque asignadoen DE, se localiza el primero libre del mismo: el bloque 0. Se actualiza el mapa deforma que refleje esta situacion: si se indexa la posicion 0, se obtiene el valor 0. Sereduce el numero de bloques libres y se redirige la peticion a DE manteniendo elmismo sector de inicio ([0]:0).

16Entre corchetes va el valor a indexar y a continuacion de los dos puntos el valor que se obtendra.

68


4. Llega una peticion de lectura del bloque 4. Se comprueba que no esta mapeado,ası que se redirige a DL ([4]:NO MAPEADO).

5. Llega una peticion de escritura del bloque 4. Se comprueba que no esta mapeado,ası que se le da el siguiente bloque libre de DE, el 1, y se redirige la peticion a esebloque ([4]:1).

6. Llega una peticion de lectura del bloque 1 ([1]:NO MAPEADO), y se redirige aDL.

Figura 4.6: Fragmentacion de un BIO en tres miniBIO.

7. Llega una peticion de escritura del bloque 1 que es redirigido a DE. Como no tieneninguno asignado ([1]:NO MAPEADO) se le da el primero libre, que resulta ser elbloque 2 ([1]:2).

8. El estado actual del mapa es el siguiente: [0]:0, [1]:2 y [4]:1. El resto de posicionescontienen el valor NO MAPEADO.

9. Llega una peticion de lectura de los bloques almacenados en las posiciones 0 a 2:[0]:0, [1]:2 y [2]:NO MAPEADO. Como se puede observar, los bloques no sonconsecutivos en DE, por lo que debera fragmentarse la peticion BIO en tres: una se

69


encargara de ir a DL y acceder al bloque 2; a DE iran dos: una al bloque 0 y otra albloque 2.

10. Llega una peticion de escritura de los bloques almacenados en las posiciones 0 a 2:[0]:0, [1]:2 y [2]:NO MAPEADO. El bloque 2 no tiene asignado un bloque dentrode DE, ası que se le da el primero libre: 3 ([2]:3). Ahora se intenta completar lapeticion, aunque debera fragmentarse en dos, pues dos son las subzonas. Todas laspeticiones iran a DE, pero una escribira en el bloque 0 y la otra escribira en losbloques 1 y 2, los cuales, al ser consecutivos en DE, pueden ser encapsulados en elmismo miniBIO.

4.3.3. Modificacion y/o fragmentacion de una peticion BIO

Toda peticion BIO que cubra varias subzonas debe ser fragmentada tantas veces comosubzonas haya. Cada fragmento sera gestionado por medio de una nueva peticion BIO,cuyos campos deberan ser inicializados o adaptados. La funcion bio alloc bioset (verpunto 4.32) devuelve una estructura BIO parcialmente inicializada, cuyos campos ter-minaran de ser inicializados mediantes los valores de la peticion BIO original (con lafuncion bio clone es posible, ademas, clonar el contenido de un BIO en otro). Ası, solosera necesario ajustar aquellos campos que hagan falta.

Figura 4.7: Ejemplo de BIO con tres segmentos que ocupan cada uno una pagina comple-tamente y que seran utilizados en la transferencia.

Los campos simples, como el sector inicial o el numero de bloques que transferir, sonfacilmente extrapolables a cada nuevo BIO, ya que basta con deducirlos a partir de lapeticion BIO inicial. En cambio, los segmentos que indican las paginas que almacenaran(lectura) o almacenan (escritura) el contenido requieren de una adaptacion especial.

Partiendo del BIO de la figura 4.7 y dependiendo de cuantas subzonas haya y cuantossegmentos necesiten, pueden ocurrir tres situaciones:

70


La subzona se compone de varios segmentos: es necesario corregir el campo bi idxpara que apunte al segmento correspondiente al bloque que se comenzara a trans-ferir. Ademas, la lista de segmentos sera un subconjunto de la original reduciendoel campo bi vcnt. Tambien podrıa ser necesario corregir el tamano del ultimo seg-mento, si no se va a utilizar completamente: si el numero de bloques que transferirno ocupa el segmento entero, es necesario reducir el campo bv len al valor exactode bytes que seran necesarios. Es importante recalcar que puede ser, o no, necesarioreducir este campo, pero nunca tendra que ser agrandado.

Figura 4.8: Creacion de un BIO que requiere de un segmento y medio de los disponibles.

La subzona se compone de parte de un segmento: el nuevo BIO creado tendra soloun segmento, el que corresponda dentro de la estructura BIO original, y ademas de-bera ajustarse el campo bv len de ese segmento, de manera similar al caso anterior.Si un trozo anterior del segmento fue empleado por otro BIO, puede ser necesarioajustar tambien el campo bv offset del primer segmento que utilizar en esta transfe-rencia.

Figura 4.9: Creacion de un BIO que requiere de medio segmento de los disponibles.

71


La subzona es la ultima: el nuevo BIO copiara la estructura de segmentos del BIOoriginal y solo debera ajustar el valor bi idx para que comience la transferencia enel segmento adecuado.

Figura 4.10: Creacion de un BIO que requiere del ultimo segmento disponible.

Una vez se han creado estos BIO que haran la labor del original, se envıan al disposi-tivo adecuado ajustando el campo bi bdev y utilizando la funcion generic make request.

Al ser BIO propios de nuestro controlador, es necesario tener cierto control sobre losmismos. Lo primero es ajustar el campo bi end io para que apunten a una funcion pro-pia donde hagan constar que han terminado. Ası, mediante esta funcion y una estructuraio info creada a tal efecto (ver listado 4.31) que relacione la peticion BIO original con losfragmentos creados, se podra deducir cuando se ha completado la peticion original pormedio de sus fragmentos.

Listado 4.31: Estructura que relaciona un BIO con varios miniBIO./∗ I n f o r m a c i o n s o b r e l o s c l o n e s ∗ /s t r u c t i o i n f o {

s t r u c t r o l l b a c k d e v ∗ dev ;i n t 3 2 t e r r o r ;s t r u c t b i o ∗ b i o ;a t o m i c t c o n t a d o r ;

} ;

dev: apunta a la instancia del dispositivo asociado al BIO.

error: indica si se ha producido algun error con cualquiera de los miniBIO generados apartir del original.

bio: peticion BIO original.

contador: indica cuantos miniBIO quedan por terminar.

72


Finalmente, queda el problema de gestionar la carencia de bloques libres en el dis-positivo de escrituras a los cuales redireccionar las escrituras. Llega un momento en elque este deposito de bloques libres se agota y no es posible mapear nuevos bloques. Ob-viamente, este problema no afecta a aquellas peticiones que intenten acceder a bloquesya mapeados en el dispositivo de escrituras. Puesto que no hay sitio donde escribir estasnuevas peticiones y el contenido de las escrituras no es crıtico (al reiniciar el sistema seperderan), se rechaza la peticion BIO mediante un error generico de E/S: EIO.

Como facilidad para con el usuario, se le avisa un tiempo antes de que quede vacıa lalista de bloques libres. Por defecto, se avisa si hay menos de un 15 % de bloques libres.Este valor es configurable a la hora de iniciar el dispositivo.

Listado 4.32: Manipulacion de estructuras BIO.s t r u c t b i o ∗ b i o a l l o c b i o s e t ( g f p t mask , i n t n r i o v e c s , s t r u c t

b i o s e t ∗ bs ) ;

vo id b i o c l o n e ( s t r u c t b i o ∗ bio , s t r u c t b i o ∗ b i o s r c ) ;

vo id g e n e r i c m a k e r e q u e s t ( s t r u c t b i o ∗ b i o ) ;

vo id b i o i o e r r o r ( s t r u c t b i o ∗ bio , u n s i g n e d i n t b y t e s d o n e ) ;

73

Capıtulo 5

CARACTERISTICAS OPCIONALES

5.1. Introduccion

En este capıtulo se explicaran algunos objetivos opcionales desarrollados. La mayorıade ellos supone mejoras en rendimiento, como un menor consumo de memoria o el usode caches de objetos, o nuevas caracterısticas, como son la posibilidad de sincronizar elcontenido del dispositivo de escrituras con el de lecturas o poder integrar el dispositivovirtual dentro del sistema make1 de Linux.

5.2. Consumo de memoria

Tal y como se explico en el capıtulo anterior, el mapa utilizado para redirigir las pe-ticiones de E/S a los distintos dispositivos es un vector cuyo tamano es el del numerode bloques del dispositivo de lecturas. Ademas, cada posicion del vector almacena unaposicion de un sector. En IA-32, el tamano del tipo sector t definido por Linux ocupa 32bits, mientras que en AMD64 su tamano es de 64 bits.

Por ejemplo, un dispositivo de lecturas de 40 GiB con un tamano de bloque de 4 KiBen IA-32:

1. Necesitarıa un vector de (40 ∗ 230 bytes) / (4 ∗ 210 bytes por bloque) = 10 ∗ 220

posiciones o bloques.

2. Cada posicion necesita almacenar un numero de sector de 32 bits o 4 bytes.

3. En total, el vector necesita 10 ∗ 220 ∗ 4 = 40 MiB de datos en espacio del nucleo.

40 MiB es una cifra respetable, pero si ademas se trabaja en una arquitectura AMD64,donde se dobla el tamano del sector, el tamano en memoria del mapa serıa de 80 MiB. Esimportante reducir esta cifra, ası que el primer paso ha sido fijar el tamano del sector a

1Make es una herramienta utilizada en la construccion automatizada de aplicaciones.

75


32 bits. Esto limita el tamano de la unidad a 2 TiB2, lo que es un valor aceptable para lasnecesidades de este proyecto.

El siguiente paso logico consiste en reducir o variar la estructura del mapa. La opcionidonea es la misma que se utiliza para almacenar los marcos de paginas de un proceso:una tabla de paginas de varios niveles.

Figura 5.1: Mapa con una estructura de dos niveles.

La idea es la siguiente: en vez de dedicar un vector gigante a almacenar los bloquesmapeados, se utilizara un vector mas pequeno, donde cada posicion apuntara a su vez aotro vector, vector que almacenara los bloques mapeados. A simple vista parece que con-sumirıa mas por el nivel de indireccion anadido. Pero esto no es ası, ya que, mientras nohaya un bloque mapeado en el vector de segundo nivel, este no existira ni ocupara memo-ria.

Por ejemplo, observando la figura 5.1 se puede ver como ya han sido mapeados aldispositivo de escrituras los bloques 0, 1 y 3071. Por el contrario, los bloques del 1024 al2047 no han sido mapeados, ası que no es necesario tener un vector encargado de mapearesa region, al menos por ahora. Si mas tarde hiciese falta mapear uno de esos bloques,por ejemplo el 1024, entonces es cuando se pedirıa memoria para esa region y, ademas, elvector que hace de mapa apuntarıa a ese vector mas pequeno para todos los accesos a esaregion.

Los vectores de segundo nivel se forman mediante paginas de memoria de 4 KiB.Cuando resulta necesario asignar un vector nuevo al vector principal, se solicita la paginay se modifica el vector principal para que apunte a ella. Al tener 4 KiB y almacenar cadacuatro bytes una posicion de sector, es posible direccionar hasta 1024 posiciones de sectorpor vector secundario.

Tomando como ejemplo el mismo dispositivo de 40 GiB con los mismos parametrosusado anteriormente, se obtendrıa el siguiente consumo de memoria:

2(232 sectores * 512 bytes por sector) / (240 bytes por TiB).

76

5.3 Sincronizacion de dispositivos

Maximo numero de vectores de segundo nivel necesarios: 10 ∗ 220 posiciones / 210

posiciones por pagina = 10 ∗ 210 paginas de 4 KiB. Es decir, 40 MiB, al igualque el vector clasico del metodo anterior. Los resultados coinciden, puesto que laconcatenacion de todos los vectores secundarios darıa lugar al vector unico utilizadohasta ahora.

Consumo inicial de memoria: 10 ∗ 210 paginas direccionadas mediante un vector depunteros. En IA-32, cada puntero ocupa cuatro bytes, ası que la memoria necesariaserıa de 10 ∗ 212 bytes o 40 KiB. En AMD64, los punteros ocupan el doble, ochobytes; por tanto, el consumo es de 10 ∗ 213 bytes u 80 KiB.

Incremento en el consumo de memoria de 4 KiB por cada nuevo vector de segundonivel.

Consumo maximo de memoria: el consumo maximo se alcanza al tener en memoriatodos los vectores secundarios mas el principal. Visto el mınimo impacto del vectorprincipal, el consumo maximo serıa igual al del modelo de vector unico.

La mejora de este modelo se da desde el primero momento, pues no necesita del vectorunico en memoria para trabajar. Al contrario, segun aumenten las necesidades ira pidiendopaginas de memoria en vez de solicitarlas todas inicialmente. En el peor de los casos, contodos los bloques mapeados, el consumo sera practicamente el mismo que el del modeloanterior.

Como beneficio adicional, en aquellos casos donde la capacidad del dispositivo de lec-turas sobrepase con mucho al de escrituras, el vector unico despilfarrara memoria, puesnunca podran mapearse todos los bloques. Con este segundo modelo, mas ahorrativo ygradual, cuando se llegue al tope de ocupacion del dispositivo de escrituras, se dejaran desolicitar paginas y, por tanto, el consumo de memoria se estancara en unos valores razo-nables. Tambien resulta util, independientemente del tamano de los dispositivos, cuandoel uso que se haga del sistema sea pequeno, es decir, no se mapeen muchos bloques.

5.3. Sincronizacion de dispositivosLa caracterıstica clave de este desarrollo es el garantizar que las modificaciones o

nuevas adiciones de datos al dispositivo de lecturas no sean permanentes. A veces, puedeexistir la necesidad de querer mantener los cambios, pero, tal y como se ha desarrolladoel sistema, no es posible.

Para atender esa necesidad se desarrollo un comando ioctl, denominado RBD SYNC,cuya labor es mezclar adecuadamente los contenidos almacenados en DE con los de DL,evitando ası la perdida de la informacion nueva. El desarrollo de una funcion que cubraese problema es muy simple; basta con copiar la informacion mapeada de DE en aquellasposiciones de DL a las que inicialmente iban dirigidas, aunque con dos condiciones: nodebe haber mas escrituras en DE mientras dure la operacion y el sistema debe tener unestado consistente antes de comenzar.

77


Estas dos restricciones se cumplen de la siguiente forma:

Estado consistente: el usuario debe desmontar el sistema de ficheros montado sobreel dispositivo virtual o, si no fuera posible, forzar que quede montado pero conpermisos exclusivamente de lectura. Cualquiera de estas dos opciones forzara lasescritura en disco de todas las peticiones pendientes, sean datos o metadatos, ydeshabilitara las escrituras en el soporte.

Deshabilitar las escrituras: aunque el paso previo ya se ha encargado de esa tarea,es posible conseguir un nivel mas de confianza rechazando, desde dentro del codi-go del dispositivo que atiende las peticiones de E/S, todas aquellas peticiones quedeseen realizar una escritura.

A nivel de implementacion, el controlador crea un BIO encargado de leer una zonamapeada en DE y, con los mismos segmentos que contienen la informacion transferida,crear otra peticion BIO que escribira los datos en DL. Este proceso se repite para todosaquellos bloques mapeados y es posible leer del dispositivo virtual, aunque no escribir.Una vez se ha terminado de sincronizar los dos soportes, se reinicia el mapa, pues no haysectores mapeados y se permiten las escrituras de nuevo. Igualmente, el dispositivo deescrituras tiene ahora todos sus bloques disponibles.

5.4. Estadısticas de acceso al dispositivoDesde al menos la rama 2.4, Linux viene proveyendo de un sistema de estadısticas

para los accesos de E/S. A partir de la version 2.4.20 para la rama estable y 2.5.45 parala de desarrollo3, se decidio mejorar este sistema y hacerlo mas exhaustivo. Desgracia-damente, apenas hay informacion sobre como usar este sistema y, por tanto, es necesariobucear en los fuentes del nucleo. Un buen punto de partida antes de analizar los fuenteses el documento iostats.txt dentro del directorio de documentacion del nucleo.

El documento iostats.txt describe los campos que se obtienen al leer el fichero virtual/proc/diskstats4 y que contienen las estadısticas recolectadas para los diferentes dispo-sitivos de bloques del sistema y sus particiones si las tuvieran. Estos mismos datos sonaccesibles mediante sysfs5, aunque solo muestran informacion del dispositivo de bloquesque se esta consultando y no de todos.

Por ejemplo, un sistema con dos dispositivos hda y hdb mostrarıa en /proc/diskstats(listado 5.1) las estadısticas para los dos discos y sus respectivas particiones, mientras quela informacion de hda se hallarıa en /sys/hda/stat (listado 5.2).

3Mas informacion sobre el sistema de numeracion de Linux: http://en.wikipedia.org/wiki/Linux kernel#Version numbering

4Se asume que el sistema de ficheros proc se encuentra montado en /proc.5Al igual que para proc, se asume que sysfs se encuentra montado en /sys.

78

5.4 Estadısticas de acceso al dispositivo

Listado 5.1: Ejemplo de fichero /proc/diskstats.3 0 hda 996 971 19314 6612 116 160 552 316 0 5216 69283 1 hda1 1942 19114 276 5523 64 hdb 22 196 421 172 0 0 0 0 0 172 1723 65 hdb1 189 189 0 0

Listado 5.2: Ejemplo de fichero /sys/block/hda/stat.996 971 19314 6612 116 160 552 316 0 5216 6928

Ademas, en cada subdirectorio de /sys/hda que correspondiese a una particion habrıaun fichero stat (listado 5.3) con las estadısticas de esa particion en concreto.

Listado 5.3: Ejemplo de fichero /sys/block/hda/hda1/stat.1942 19114 276 552

5.4.1. Estructura del fichero diskstats

La estructura de los campos para un disco serıa la siguiente:

1. Numero de lecturas completadas.

2. Numero de lecturas combinadas: son lecturas adyacentes en el disco y que, portanto, se pueden combinar en una unica peticion. Por ejemplo, dos lecturas de 4KiB de dos zonas adyacentes en el disco daran lugar a una lectura de 8 KiB. Estecampo indica cuan a menudo se ha realizado este tipo de combinacion.

3. Numero de sectores leıdos.

4. Tiempo en milisegundos invertido en lecturas: este campo abarca desde que se lanzala peticion con make request() hasta que end that request last() la da por termi-nada.

5. Numero de escrituras completadas.

6. Numero de escrituras combinadas: igual que el punto 2, pero relativo a las escritu-ras.

7. Numero de sectores escritos.

8. Tiempo en milisegundos invertido en escrituras: igual que el punto 4, pero relativoa las escrituras.

9. Numero de operaciones de E/S en proceso: es el unico campo que debe valer casiconstantemente cero. Se incrementa cuando se encola una peticion en la cola depeticiones adecuada y se decrementa cuando concluye la peticion.

79


10. Tiempo en milisegundos invertido en operaciones de E/S: este campo se incrementamientras haya alguna operacion de E/S en proceso.

11. Tiempo total en milisegundos invertido en E/S: a diferencia del campo anterior, estecampo refleja la suma total del tiempo invertido en satisfacer cada peticion de E/S.Su valor suele aproximarse a la suma de los tiempos del campo 4 y 8.

Un detalle importante es que la lectura de estos contadores se realiza sin seccionescrıticas para evitar cuellos de botella. A cambio, se pierde algo de precision si hay accesosconcurrentes a estos campos.

5.4.2. Estructura disk statsYa que el fichero /proc/diskstats informa de los valores que se quieren medir, es logi-

co comenzar a explorar los fuentes del nucleo buscando el punto donde se crea dichofichero. Este fichero virtual se ha creado, junto con muchos mas que aportan todo tipode informacion sobre Linux, en fs/proc/proc misc.c:proc misc init. Y la funcion encarga-da de volcar las estadısticas es block/genhd.c:diskstats show. Dentro de esta funcion seobserva como los datos que imprime los obtiene mediante una llamada a disk stat read,que es una macro que vuelca el campo indicado de la estructura disk stats dentro de laestructura gendisk que describe al disco. Por tanto, la estructura disk stats es la encargadade almacenar las estadısticas de cada disco del sistema.

La definicion de la estructura disk stats se puede ver en el listado 5.4.

Listado 5.4: Estructura disk stats.# i n c l u d e < l i n u x / genhd . h>

s t r u c t d i s k s t a t s {u n s i g n e d long s e c t o r s [ 2 ] ; /∗ READs and WRITEs ∗ /u n s i g n e d long i o s [ 2 ] ;u n s i g n e d long merges [ 2 ] ;u n s i g n e d long t i c k s [ 2 ] ;u n s i g n e d long i o t i c k s ;u n s i g n e d long t i m e i n q u e u e ;

} ;

Es facil establecer una correlacion entre los campos de esta estructura y los de laestructura del fichero diskstats descrita en el punto anterior:

sectors: vector de dos posiciones que contiene los sectores leıdos y escritos. Se corres-ponde con los campos tres y siete del punto anterior.

ios: vector de dos posiciones que contiene el numero de peticiones de lectura y escriturarealizadas. Se corresponde con los campos uno y cinco del punto anterior.

merges: vector de dos posiciones que contiene el numero de peticiones de lectura y es-critura que se han combinado. Se corresponde con los campos dos y seis del puntoanterior.

80

5.4 Estadısticas de acceso al dispositivo

ticks: vector de dos posiciones que contiene los jiffies utilizados en satisfacer las ope-raciones de lectura y escritura. Se corresponde con los campos cuatro y ocho delpunto anterior.

io ticks: almacena los jiffies utilizados en operaciones de E/S. Se corresponde con elcampo diez del punto anterior.

time in queue: almacena la suma total de los jiffies utilizados para realizar cada una delas operaciones de E/S. Se corresponde con el campo once del punto anterior.

Es necesario aclarar un par de puntos relativos a la estructura descrita:

En los vectores, todos ellos de dos posiciones, la posicion cero corresponde a lalectura y la posicion uno a la escritura.

Los jiffies6 son realmente los tics del reloj del sistema y se suelen usar como me-dida de tiempo en los sistemas operativos. Por tanto, para mostrar estos valores alusuario es necesario convertirlos previamente a milisegundos mediante la funcionjiffies to msecs.

La parte del nucleo que trata las colas de peticiones de los dispositivos tambien seencarga de actualizar estos contadores. Para ello, analiza la peticion e incrementa los con-tadores correspondientes. Esto no sucede con los dispositivos virtuales ya que no suelentener colas de peticiones al uso, al carecer de un dispositivo fısico al que enviar las peti-ciones. En nuestro caso, cuando llega una peticion, se analiza, se fragmenta, si hace falta,y se envıa a la cola de peticiones del verdadero dispositivo fısico. Por tanto, no se actua-lizan los contadores y es necesario hacerlo manualmente por medio de las macros queofrece Linux.

5.4.3. Macro disk stat add

La macro disk stat add se encarga de incrementar el contador indicado en una canti-dad determinada. Su definicion se puede ver en el listado 5.5.

Listado 5.5: Funcion disk stat add.# i n c l u d e < l i n u x / genhd . h>

d i s k s t a t a d d ( gend i skp , f i e l d , addnd )

gendiskp: estructura gendisk que describe el dispositivo.

field: el campo de la estructura disk stats que se va a incrementar.

addnd: valor que se sumara al contador.

6http://en.wikipedia.org/wiki/Jiffie

81


Esta macro se utiliza para modificar el contador sectors (ver listado 5.6) que se encargade anotar el numero de sectores leıdos y escritos en el dispositivo.

Listado 5.6: Actualizacion de estadısticas.i n t mapeo make reques t ( r e q u e s t q u e u e t ∗ q , s t r u c t b i o ∗ b i o ){. . .

/∗ A c t u a l i z a r l a s e s t a d i s t i c a s de a cc es o ∗ /d i s k s t a t a d d ( dev−>d i s c o , s e c t o r s [ b i o d a t a d i r ( b i o ) ] ,

b i o s e c t o r s ( b i o ) ) ;d i s k s t a t i n c ( dev−>d i s c o , i o s [ b i o d a t a d i r ( b i o ) ] ) ;

. . .}

Los campos ticks, io ticks y time in queue no seran actualizados nunca. El motivo esel siguiente: las peticiones que es necesario fragmentar y reenviar, una vez han sido satis-fechas, vuelven al codigo del controlador, siendo muy facil indicar el tiempo invertido porcada peticion. Pero hay peticiones que no es necesario fragmentar y, por tanto, nunca vol-veran al codigo del controlador; esto impide que se pueda contabilizar el tiempo que hanempleado, a no ser que se sustituya la funcion de finalizacion del BIO bio->bi end io poruna propia. Esta funcion actualizarıa los contadores y procederıa a invocar la funcion ori-ginal sustituida. Los inconvenientes son mas complejidad en el codigo y una penalizacionen el tiempo necesario para el tratamiento de estas peticiones. Por tanto, se ha desechadola idea de actualizar todos estos contadores que se encargan de medir de alguna forma eltiempo empleado en el dispositivo.

5.4.4. Macro disk stat incLa macro disk stat inc es una particularizacion de la macro anterior. Su labor es in-

crementar siempre en uno el valor del contador indicado. Su definicion se puede ver en ellistado 5.7.

Listado 5.7: Funcion disk stat inc.# i n c l u d e < l i n u x / genhd . h>

d i s k s t a t i n c ( gend i skp , f i e l d )

gendiskp: estructura gendisk que describe el dispositivo.

field: el campo de la estructura disk stats que se incrementara en uno.

Esta macro se utiliza para modificar el contador ios (ver listado 5.6) que se encarga deanotar el numero de peticiones de lectura y escritura realizadas en el dispositivo.

Tampoco se actualizara el campo merges. La razon tras esta decision es que las peti-ciones no se combinan nunca, pues siempre deben traducirse y posiblemente fragmentarse

82

5.5 Soporte para blktrace

en peticiones mas pequenas que se redirigen a los dispositivos adecuados. En las colas deesos dispositivos es donde se combinaran las peticiones que hubiera, si fuera necesario.Esta labor la realizarıa el gestor de colas de dispositivos de Linux.

5.5. Soporte para blktraceLa herramienta blktrace7, desarrollada por Jens Axboe, permite observar lo que sucede

en la capa de E/S de bloques, concretamente como se tratan y resuelven las peticiones deE/S enviadas.

Listado 5.8: Funciones de blktrace.# i n c l u d e < l i n u x / b l k t r a c e a p i . h>

vo id b l k a d d t r a c e b i o ( s t r u c t r e q u e s t q u e u e ∗q , s t r u c t b i o ∗ bio ,u32 what ) ;

vo id b l k a d d t r a c e r e m a p ( s t r u c t r e q u e s t q u e u e ∗q , s t r u c t b i o∗ bio , d e v t dev , s e c t o r t from , s e c t o r t t o ) ;

q: cola del dispositivo que trata el BIO.

bio: BIO del que anotar la traza.

what: identifica el tipo de traza que anadir.

dev: dispositivo que procesara el BIO.

from: sector original del BIO.

to: sector al que se ha mapeado el BIO.

Aunque hay mas funciones disponibles para anotar las trazas, se ha decidido mostraraquellas importantes en el desarrollo del proyecto. Como ya se ha comentado varias veces,al ser un dispositivo virtual, todos los BIO que le llegan son reenviados a un dispositivoque sı tratara la peticion. Ası que las trazas que hay que anotar seran aquellas que, o bienexpresen la operacion de mapeo, o bien anoten la finalizacion de un BIO por medio desus miniBIO.

Para aquellas peticiones que son mapeadas se utiliza la funcion blk add trace remap.Los parametros importantes son los relativos a los sectores: cual era el sector original y acual se ha decidido mapear el BIO.

7http://linux.die.net/man/8/blktrace

83


Listado 5.9: Uso de blk add trace remap./∗ G e s t i o n a l a p e t i c i o n BIO ∗ /i n t 3 2 t mapeo make reques t ( r e q u e s t q u e u e t ∗ q , s t r u c t b i o ∗

b i o ){

. . .b l k a d d t r a c e r e m a p ( b d e v g e t q u e u e ( bio−>b i b d e v ) , b io ,

b d e v o r i g i n a l −>bd dev , s e c t o r o r i g i n a l , b io−>b i s e c t o r ) ;. . .

}

/∗ Termina de i n i c i a l i z a r e l BIO y l o e n v i a a l d i s p o s i t i v o ∗ /s t a t i c vo id e n v i a r b i o ( s t r u c t i o i n f o ∗ io , s t r u c t b i o ∗ bio ,

boo l o r i g i n a l ){

. . .b l k a d d t r a c e r e m a p ( b d e v g e t q u e u e ( bio−>b i b d e v ) , b io ,

io−>bio−>b i bdev−>bd dev , s e c t o r o r i g i n a l ,b io−>b i s e c t o r ) ;

. . .}

Cuando es necesario fragmentar un BIO en varios miniBIO por abarcar varias sub-zonas, se espera a la finalizacion de todos los miniBIO relacionados con ese BIO. Unavez sucede esto, se puede avisar al emisor del BIO de que este ha sido completado.Para anadir esta informacion como traza se usa la funcion blk add trace bio, indican-do mediante el parametro what, el tipo de traza que se esta anotando. El valor usado esBLK TA COMPLETE.

Listado 5.10: Uso de blk add trace bio.s t a t i c vo id d e c p e n d i n g ( s t r u c t i o i n f o ∗ io , i n t 3 2 t e r r o r ){

. . .b l k a d d t r a c e b i o ( io−>dev−>co la , io−>bio , BLK TA COMPLETE) ;. . .

}

5.6. Cache de objetosLinux implementa caches o almacenes de aquellos objetos que suelan ser reutilizados

a menudo. Tomese como ejemplo el caso de los BIO, que constantemente estan siendocreados, procesados y eliminados. Cada vez que se quiere enviar una peticion de E/S esnecesario pedir la estructura al nucleo, para que la inicialice correctamente. El nucleo,para no estar pidiendo y liberando memoria constantemente, crea un conjunto de estruc-turas BIO que ira sirviendo a aquellos que las necesiten. Una vez terminen de usar la

84

5.6 Cache de objetos

estructura, esta es devuelta al nucleo, aunque no liberada por este. Simplemente se dejaen memoria hasta que vuelva a ser necesaria, en cuyo caso se reinicializaran sus camposy se entregara como si hubiera sido creada para esa ocasion.

Aunque el nucleo ya tiene su propia cache o almacen de BIO, no esta de mas queel controlador tenga el suyo propio. Este almacen resultarıa beneficioso, ya que la posi-bilidad de que haya que fragmentar un BIO en varios miniBIO es muy alta y, por cadaminiBIO, harıa falta una estructura BIO.

Linux tiene en cuenta esta necesidad y permite definir una cache de objetos BIO:

La funcion bioset create se encarga de crear el conjunto necesario de BIO. Es ne-cesario indicarle a la funcion el numero de BIO y el numero de segmentos que sequieren tener disponibles. Es necesario indicar el numero de segmentos, ya que losBIO dependen, en gran medida, de estos para las transferencias. De nada servirıatener los BIO siempre disponibles si no hay segmentos con los que operar.

Mediante bioset free se libera la memoria que ocupan los segmentos y los BIOpreasignados.

Una vez ha sido creado el conjunto de BIO, se podra disponer de ellos mediante lafuncion bio alloc bioset, indicando el numero de segmentos que se requieren parael BIO.

Finalmente, se devuelve el BIO y los segmentos al almacen mediante la funcionbio free.

Listado 5.11: Gestion de la cache de BIO.# i n c l u d e < l i n u x / b i o . h>

s t r u c t b i o s e t ∗ b i o s e t c r e a t e ( i n t b i o p o o l s i z e , i n tb v e c p o o l s i z e ) ;

vo id b i o s e t f r e e ( s t r u c t b i o s e t ∗ bs ) ;

s t r u c t b i o ∗ b i o a l l o c b i o s e t ( g f p t gfp mask , i n t n r i o v e c s ,s t r u c t b i o s e t ∗ bs ) ;

vo id b i o f r e e ( s t r u c t b i o ∗ bio , s t r u c t b i o s e t ∗ b i o s e t )

Ademas de los BIO, hay otra estructura, no definida en el nucleo, sino en el proyecto,que es utilizada a menudo por los mismo motivos que los expuestos anteriormente. Laestructura io info es la encargada de enlazar el BIO original con los miniBIO que estanrealizando realmente la operacion. Por tanto, por cada BIO fragmentado, es necesariotener una estructura de este tipo. Al ser una estructura propia de la solucion, hay queusar unas funciones similares a las anteriores, pero mas genericas, disenadas para dar elsoporte de caches a estructuras propias del programador.

Las funciones disponibles son las siguientes:

85


La funcion mempool create slab pool es la encargada de crear el almacen de estruc-turas. Recibe la estructura de la que crear multiples copias y el numero de copiasque se desea tener siempre disponible.

La funcion mempool destroy libera el espacio ocupado por todas las instancias, esdecir, el almacen al completo.

mempool alloc es la funcion utilizada para solicitar una instancia de las disponibles.

Finalmente, mempool free retorna al almacen la estructura despues de usada, paraque este disponible para quien la solicite.

Listado 5.12: Gestion de la cache de objetos.# i n c l u d e < l i n u x / mempool . h>

mempool t m e m p o o l c r e a t e s l a b p o o l ( i n t min nr , s t r u c t kmem cache∗kc )

vo id mempoo l des t roy ( mempool t ∗ poo l ) ;

vo id ∗ mempoo l a l l oc ( mempool t ∗ pool , g f p t gfp mask ) ;

vo id mempool f ree ( vo id ∗ e lement , mempool t ∗ poo l ) ;

Si se estudia la implementacion de las funciones encargadas de crear la cache de BIOen Linux, se observara que actuan como una capa adicional, especıfica para BIO, situadaencima de las funciones genericas encargadas de crear y tratar el almacen de estructurasdeseado.

5.7. Utilizacion de macros de LinuxLinux dispone de una serie de macros que facilitan el acceso a determinados campos

de algunas estructuras. Se suele sugerir que se empleen, porque ademas, si en algun mo-mento un campo de una estructura es renombrado o modificado, aquellas funciones quehagan uso de la macro seguiran funcionando correctamente sin modificacion alguna.

Listado 5.13: Macro bio data dir.# i n c l u d e < l i n u x / f s . h>

# d e f i n e b i o d a t a d i r ( b i o ) ( ( b i o )−>b i r w & 1)

Ejemplos de las macros utilizadas son bio data dir (ver listado 5.13) o bio iovec idx(ver listado 5.14). Ası bio data devuelve true si el BIO pasado como parametro corres-ponde a una escritura; en caso de una lectura devuelve false. Y bio iovec idx devuelve la

86

5.7 Utilizacion de macros de Linux

estructura bio vec, del BIO pasado como parametro, que va a utilizarse en la transferen-cia de datos. La macro bio sectors devuelve el numero de sectores que intervendran en latransferencia.

Listado 5.14: Macros bio iovec dix y bio sectors.# i n c l u d e < l i n u x / b i o . h>

# d e f i n e b i o i o v e c i d x ( bio , i d x ) (&( ( b i o )−>b i i o v e c [ ( i d x ) ] ) )

# d e f i n e b i o s e c t o r s ( b i o ) ( ( b i o )−>b i s i z e >> 9)

Ademas de este tipo de macros, hay otro tipo cuya mision es optimizar el codigo objetogenerado. La macro likely se usa en aquellos chequeos o comprobaciones cuya respuestase sabe que va a ser cierta, o true, en la mayorıa de los casos. Por contra, la macro unlikelyes usada en las comprobaciones que se sabe que tienen una alta probabilidad de fallar.

Listado 5.15: Macros likely y unlikely.# d e f i n e l i k e l y ( x ) b u i l t i n e x p e c t ( ! ! ( x ) , 1 )

# d e f i n e u n l i k e l y ( x ) b u i l t i n e x p e c t ( ! ! ( x ) , 0 )

Normalmente, al generar codigo para un bloque condicional o comprobacion, se haceque salte o no el flujo de ejecucion dependiendo del resultado de la comprobacion. Lossaltos perjudican el rendimiento, ya que suele ser necesario vaciar el pipeline8 e introduciren el mismo las instrucciones correspondientes a la zona de salto.

Cuando el compilador esta generando codigo objeto y encuentra estas macros decideemitir instrucciones que hagan variar el flujo de ejecucion, es decir, saltar, en el casomenos probable.

Listado 5.16: Ejemplo de uso de la macro unlikely.s t a t i c s t r u c t b i o ∗ b i o s y n c c r e a r ( s t r u c t b l o c k d e v i c e ∗ dev ,

u i n t 3 2 t num paginas , s e c t o r 3 2 t s e c t o r , u i n t 3 2 t rw ){

. . ./∗ Crear BIO ∗ /

b i o = b i o a l l o c ( GFP NOIO , num paginas ) ;i f ( u n l i k e l y ( b i o == NULL) ) {

p r i n t k (KERN ERR ” rbd : u n a b l e t o a l l o c a t e b i o .\ n ” ) ;r e t u r n ERR PTR(−ENOMEM) ;

}}

8Un pipeline es un conjunto de etapas conectadas entre sı de forma que la salida de una es la entradade otra. Las instrucciones atraviesan estas etapas de una en una para poder realizar su labor. Al estar seg-mentado se pueden paralelizar las etapas de forma que todas trabajen a la vez aunque cada una tenga unafuncion distinta y ası mejorar el rendimiento.

87


En el ejemplo 5.16, se ha indicado que es poco probable que falle la creacion deun nuevo BIO por medio de bio alloc, ası que el codigo objeto generado, en la zonacorrespondiente a este ejemplo, tendra una instruccion de salto para el caso de que fallela comprobacion. Como es poco probable que esto suceda, el salto se tomara muy pocasveces, penalizando menos que si fuera al reves: que se saltara si la creacion de un nuevoBIO fuese exitosa.

Obviamente, estas dos macros solo deben utilizarse cuando se sepa con bastante se-guridad cual va a ser el desarrollo normal de los chequeos. En caso contrario, puedenpenalizar mas que ayudar.

5.8. Integracion con el sistema de compilacion del nucleoLinux

Linux se apoya en la herramienta Make para crear imagenes y modulos a partir de losficheros fuente. Mediante un menu se puede seleccionar el hardware para el cual se deseaque Linux incluya soporte. Ademas, se pueden configurar multitud de opciones que vandesde el soporte de carga y descarga de modulos hasta los sistemas de ficheros a los quese desea dar soporte pasando por determinadas caracterısticas de ahorro de energıa.

Para gestionar los ficheros fuente usa dos tipos de archivo:

Kconfig: contiene informacion que se mostrara al usuario cuando, mediante el menu,personalice su compilacion de Linux (ver listado 5.17).

Makefile: contiene informacion para el sistema de compilacion acerca de los objetivos oficheros objeto que se pueden generar (ver listado 5.18).

Partiendo de esta base, se ha creado unos ficheros Kconfig (listado 5.17) y Makefile(listado 5.18) propios, para permitir al usuario seleccionar la compilacion, y opcionalintegracion, del codigo del controlador del dispositivo virtual.

Todo el desarrollo de la solucion se ha confinado dentro de un parche que puedeser aplicado sobre cualquier revision de Linux 2.6.24, facilitando ası su distribucion. Elmenu de compilacion de Linux, una vez aplicado el parche, quedarıa modificado parapermitir la compilacion de la solucion. La aplicacion de control del usuario se distribuyecomo un fichero unico que debera ser compilado de forma tradicional, independientemen-te del sistema de compilacion del nucleo Linux.

Listado 5.17: Fichero Kconfig del controlador.## Block d e v i c e d r i v e r c o n f i g u r a t i o n#

c o n f i g BLK DEV RBDt r i s t a t e ” Rol lBack d e v i c e s u p p o r t ”h e l p

Adds s u p p o r t f o r t h e r o l l b a c k d e v i c e .

88

5.8 Integracion con el sistema de compilacion del nucleo Linux

Listado 5.18: Fichero Makefile del controlador.## M a k e f i l e f o r t h e Rol lBack d e v i c e#

obj−$ ( CONFIG BLK DEV RBD ) += rbd . orbd−o b j s := d e v i c e . o map . o

89

Capıtulo 6

CONCLUSIONES Y FUTURASLINEAS

6.1. ConclusionesBrevemente, los objetivos del proyecto eran los siguientes:

1. Proponer y desarrollar una solucion que permitiese modificar el contenido deun sistema de ficheros, sin que estas modificaciones fuesen permanentes: se hanpropuesto varias alternativas, discutiendose sus beneficios e inconvenientes, y se haescogido aquella que ha parecido mas sensata y correcta. Durante la explicacion deldesarrollo e implementacion de la solucion, se ha podido observar que, en ningunmomento, una vez este en marcha la solucion, se modificara el dispositivo de lec-turas y que, en conjuncion con el dispositivo de escrituras, el dispositivo virtualofrecera una imagen al usuario que sera combinacion de los otros dos dispositivos.

2. La solucion debıa funcionar en Linux: la solucion funciona exclusivamente enLinux por su dependencia del modulo desarrollado.

3. Debıa ser lo mas generica posible: la solucion es generica en el sentido de que noesta atada a un sistema de ficheros, sino que funciona con aquellos que delimiten elespacio dentro del soporte con bloques del mismo tamano.

4. Las modificaciones no debıan mantenerse en memoria, sino en otro soporte,por ejemplo particiones o ficheros: todas las modificaciones se vuelcan al dis-positivo de escrituras elegido, manteniendo en memoria las estructuras necesariaspara operar y aquellos datos que mantenga en cache el propio Linux.

5. El usuario no deberıa notar diferencia alguna entre un sistema con la solucionen marcha y otro sin ella, salvo en que las modificaciones realizadas no son per-manentes: para el usuario, la unica diferencia podrıa ser una ligera penalizacion enel rendimiento por la manipulacion adicional a la que son sometidas las peticionesBIO.

91

CONCLUSIONES Y FUTURAS LINEAS

6. Los cambios serıan deshechos automaticamente al apagar el equipo. Opcio-nalmente, una aplicacion de apoyo podrıa realizar esta misma tarea sin tener quereiniciar: puesto que las estructuras de control estan en memoria, una vez se apagueel equipo o se fuerce la reinicializacion de las estructuras por medio de la aplicacionde control, las escrituras seran inaccesibles para el usuario. Seguiran estando en eldispositivo de escrituras, pero no se podran recuperar en el sentido de que no hayinformacion que permita relacionar los bloques ahı almacenados con aquellos a losque debieran sustituir en el dispositivo de lecturas.

7. Opcionalmente, el sistema de ficheros raız podrıa funcionar bajo el control dela solucion, de forma que los cambios en el efectuados sean temporales: no haynada en el desarrollo de la solucion que impida que el sistema raız sea montadoencima del dispositivo virtual. Esta configuracion fue probada y lo unico necesarioes, al igual que con los sistemas RAID, poder activar el dispositivo antes de quellegue a montarse el sistema raız. Esto se consigue por medio de:

a) Un sistema raız mınimo, que sera cargado exclusivamente en memoria, y des-de el que se operara para poder crear el dispositivo virtual, antes de montar elsistema raız, normalmente embebido dentro de la imagen del nucleo.

b) La aplicacion rbdctl. Es necesario que esta y todas las aplicaciones que seutilicen durante el arranque esten compiladas estaticamente, para no dependerde biblioteca alguna.

c) Un interprete de comandos junto con un script encargado de invocar la apli-cacion rbdctl y crear el dispositivo rbd. Posteriormente, el script debera pasarel control al proceso init.

Los objetivos obligatorios descritos hasta ahora han sido alcanzados plenamente. Seha anadido otro objetivo opcional: la posibilidad de evitar perder los cambios y mantener-los. Para ello, se sincroniza el contenido del dispositivo de escrituras con el de lecturas,dando lugar a un dispositivo de lecturas modificado realmente tal y como se veıa a travesdel dispositivo virtual.

Ademas, el que los dispositivos de lecturas y escrituras sean eso, dispositivos de blo-ques, permite utilizar un amplio abanico de posibilidades: particiones en discos IDE, SA-TA y USB, discos virtuales en memoria, ficheros mostrados como dispositivos por mediodel dispositivo loop1, etc. Si se dispone de suficiente memoria, es preferible crear un discovirtual en memoria, de forma que las escrituras se redirijan a ese hardware, mucho masveloz que un disco.

Mediante la herramienta rbdctl se puede conocer el estado de cada dispositivo virtual,sobre todo informacion importante, como el nivel de ocupacion de los bloques libres deldispositivo de escrituras y el consumo actual en memoria del mapa.

Finalmente, durante la fase de testeo se realizaron pruebas con varios tamanos de blo-que (1024, 2048 y 4096 bytes) y con distintos sistemas de ficheros (Ext2, Ext3, ReiserFSy JFS), y la solucion funciono perfectamente.

1http://en.wikipedia.org/wiki/Loop device

92

6.2 Futuras lıneas

6.2. Futuras lıneasLa solucion, aunque cumple los objetivos y es completamente funcional, puede ser

mejorada anadiendo alguna de las siguientes caracterısticas:

Interfaz grafica: a pesar de la simplicidad que ofrece la herramienta rbdctl desde lıneade comandos, una interfaz grafica siempre es mas comoda de usar.

Persistencia: una vez se reinicia el equipo, los datos del dispositivo de escrituras dejande estar disponibles. Siguen ahı, pero no se tiene el mapa que relaciona su conteni-do con los bloques del dispositivo de lecturas. Almacenar de alguna forma el mapa,quiza en el propio soporte de escrituras, serıa una posible solucion para seguir dis-poniendo de los datos modificados, aunque en el futuro estos sean rechazados.

Puntos de restauracion: un paso mas con respecto a la persistencia serıa el soporte paravarias puntos de restauracion. Se podrıa congelar el estado actual del dispositivo deescrituras e iniciar otro mapa desde cero, como si se comenzase a utilizar el disposi-tivo virtual. Ası, serıa posible realizar modificaciones sobre cambios ya realizadosantes del punto de restauracion y volver a cualquiera de los puntos guardados, hastael original.

Soporte de mas sistemas de ficheros: la solucion, como ya se ha comentado, ha sidoprobada satisfactoriamente con los sistemas de ficheros Ext2, Ext3, ReiserFS y JFS,pero todavıa quedan mas sistemas como XFS o Reiser4. Por tanto, estos sistemasdeberıan probarse y, si fuera necesario, debera modificarse el controlador para dar-les soporte.

Funcion identidad como mapa: si el soporte de escrituras tiene un tamano igual o ma-yor que el de lecturas, no harıa falta mapa alguno. Se podrıa utilizar una funcionidentidad para relacionar los dos soportes, de forma que el bloque X del dispositivode lecturas se corresponde con el mismo bloque, pero en el dispositivo de escrituras.

Comparticion del soporte de escrituras: cada dispositivo virtual relaciona un disposi-tivo de lecturas con uno de escrituras. Si se compartiera el espacio del dispositivode escrituras entre varias instancias del dispositivo virtual, podrıa ahorrarse espacio,de forma que no hubiera que utilizar exclusivamente un soporte de escrituras dis-tinto para cada instancia del dispositivo virtual. Es mas, quiza podrıan combinarsevarios soportes de escrituras como un unico soporte, similar a un RAID 0, y utilizarese espacio de forma comun entre las distintas instancias del dispositivo virtual a lahora de escribir.

Hibernar y suspender: el soporte para la transicion a los estados de suspension e hiber-nacion, no se ha probado por considerar que estas caracterısticas estan todavıa endesarrollo en Linux. Una vez se estabilicen estas dos caracterısticas deberıa estu-diarse si el controlador tiene problemas a la hora de transitar a esos estados y, encaso afirmativo, solucionarlo.

93

CONCLUSIONES Y FUTURAS LINEAS

6.3. EstadısticasUn poco al margen de lo ya comentado, se ofrecen algunos datos relacionados con el

desarrollo del proyecto:

El proyecto dio comienzo a finales de diciembre de 2006 y se completo a finales dejunio de 2008.

La implementacion de la solucion tuvo lugar desde febrero del 2007 hasta principiosde abril del 2008.

La memoria del proyecto se redacto durante el perıodo que va desde febrero de 2008hasta finales de junio del mismo ano, partiendo de anotaciones realizadas durantela fase de implementacion.

La solucion se compone de 1080 SLOC2 C para el controlador y 399 para la herra-mienta de control rbdctl. A pesar de no ser muchas lıneas, el mayor problema en eldesarrollo estuvo en el particular y restrictivo entorno de ejecucion que supone unnucleo Linux y la dispersa y escasa documentacion existente.

Figura 6.1: Grafica correspondiente a la evolucion de las lıneas de codigo de la solucion.

2Source Lines Of Code es una metrica software usada para medir el tamano de un desarrollo softwaremediante la cuenta del numero de lıneas en los fuentes del programa, despreciando las que esten en blancoo sean comentarios.

94

6.3 Estadısticas

En la imagen 6.1 se puede observar cual ha sido la evolucion en lıneas de codigo a lolargo del tiempo. El software utilizado para generar estadısticas, a partir del repositorioSubversion3, StatSVN4, indica erroneamente un aumento de 2900 lıneas a 4000 a princi-pios de abril. En esas fechas se renombraron varios ficheros del proyecto y StatSVN, porerror, suma dos veces los ficheros implicados.

3Subversion es un sistema de control de versiones derivado de CVS.4http://www.statsvn.org/

95

BIBLIOGRAFIA

Documentos impresos* BOVET, Daniel P.; CESATI, Marco. Understanding the Linux Kernel. 3a ed. Esta-

dos Unidos: O’Reilly Media, 2005. 942 p. ISBN: 0-596-00565-2.

* CORBET, Jonathan; RUBINI, Alessandro; KROAH-HARTMAN, Greg. Linux De-vice Drivers. 3a ed. Estados Unidos: O’Reilly Media, 2005. 636 p. ISBN: 0-596-00590-3.

Documentos electronicos* ANDREWS, Jeremy. KernelTrap.

http://kerneltrap.org/

* CARD, Remy; TS’O, Theodore; TWEEDIE, Stephen. Design and Implementationof the Second Extended Filesystem.http://e2fsprogs.sourceforge.net/ext2intro.html

* Eklektix, Inc. Linux Weekly News.http://lwn.net/

* GLEDITSCH, Arne Georg. The Linux Cross Reference.http://lxr.linux.no/

* JONES, M. Tim. Anatomy of Linux synchronization methods.http://www.ibm.com/developerworks/linux/library/l-linux-synchronization.html

* SPAANS, Jasper. The Linux Kernel Mailing List Archive.http://lkml.org/

* Wikimedia Foundation, Inc. Wikipedia, la enciclopedia libre.http://es.wikipedia.org/wiki/Portada

97

Apendice A

INSTRUCCIONES DECOMPILACION Y USO

A.1. IntroduccionEl CD que se adjunta a este libro contiene tres directorios:

doc: contiene esta memoria en formato PDF.

src: contiene los fuentes del controlador para Linux y los de la aplicacion de controlrbdctl.

test: contiene el parche que se puede aplicar a los fuentes de Linux en su version 2.6.24y un script1 para comprobar el correcto funcionamiento de la solucion.

A.2. Dispositivo virtual

A.2.1. Compilacion e instalacionEl dispositivo virtual requiere de los fuentes de Linux 2.6.24, ademas de las herra-

mientas que permiten compilar los fuentes: GCC, Make, binutils, etc.Cuando se tengan los fuentes descomprimidos, es necesario parchearlos con el fichero

test/rbd 2.6.24.patch desde dentro del directorio linux-2.6.24.

Listado A.1: Aplicar el parche a los fuentes de Linux 2.6.24$ p a t c h −p1 < r b d 2 . 6 . 2 4 . p a t c hp a t c h i n g f i l e l i n u x −2 . 6 . 2 4 / d r i v e r s / Kconf igp a t c h i n g f i l e l i n u x −2 . 6 . 2 4 / d r i v e r s / M a k e f i l ep a t c h i n g f i l e l i n u x −2 . 6 . 2 4 / d r i v e r s / rbd / d e v i c e . cp a t c h i n g f i l e l i n u x −2 . 6 . 2 4 / d r i v e r s / rbd / Kconf igp a t c h i n g f i l e l i n u x −2 . 6 . 2 4 / d r i v e r s / rbd / M a k e f i l e

1Un script es un fichero que contiene una secuencia de ordenes que ejecutar.

99

INSTRUCCIONES DE COMPILACION Y USO

p a t c h i n g f i l e l i n u x −2 . 6 . 2 4 / d r i v e r s / rbd / map . cp a t c h i n g f i l e l i n u x −2 . 6 . 2 4 / d r i v e r s / rbd / map . hp a t c h i n g f i l e l i n u x −2 . 6 . 2 4 / i n c l u d e / l i n u x / map . h

Una vez aplicado el parche, ya se puede configurar la imagen como se desee. Launica diferencia sera que, dentro del apartado Device Drivers, habra un nuevo elemento:RollBack device support. Este elemento puede ser integrado en la imagen que se va agenerar o ser compilado como modulo para ser cargado cuando sea necesario.

A.2.2. Inicializacion del modulo

Si el controlador ha sido integrado en la imagen, al arrancar existira un nuevo dis-positivo /dev/rbd0. Si por contra, se ha compilado como modulo, podran crearse masdispositivos virtuales al cargar el modulo en memoria. Para ello, basta cargarlo y darle elvalor deseado al parametro max rbd.

Por ejemplo, la carga con el parametro max rbd con el valor tres creara los dispositivosdel listado A.2.

Listado A.2: Dispositivos creados en /dev/ usando el valor 3 con el parametro max rbd.brw−rw−−−− 1 r o o t d i s k 240 , 0 2008−06−18 18 :02 / dev / rbd0brw−rw−−−− 1 r o o t d i s k 240 , 1 2008−06−18 18 :02 / dev / rbd1brw−rw−−−− 1 r o o t d i s k 240 , 2 2008−06−18 18 :02 / dev / rbd2

A.3. Aplicacion de control

A.3.1. Compilacion e instalacion

La aplicacion de control se encuentra dentro del directorio src/rbdctl y, para generarla,basta con ejecutar make dentro del mismo.

A pesar de que debera reconocer los formatos de las particiones Ext2, Ext3, ReiserFSy JFS no utiliza las bibliotecas que ofrece cada uno de estos sistemas de ficheros. Larazon es que solo son necesarias para descubrir el tamano del bloque de la particion yeso se puede hacer recorriendo la particion, si se sabe donde se almacenan los datos.Lo hace menos tolerable a cambios en la estructura logica de la particion, pero muchomas portable. La aplicacion junto con el modulo han sido probadas satisfactoriamente enarquitecturas IA-32 y AMD64.

A.3.2. Uso

Para que funcione la aplicacion es necesario que el controlador este integrado en elnucleo, ya sea por compilacion o cargado como modulo. Una vez cumplido este punto, laherramienta rbdctl dispone de varias opciones para su ejecucion (listado A.3).

100

A.3 Aplicacion de control

Listado A.3: Salida por pantalla de rbdctl sin opciones.$ r b d c t lr b d c t l 0 . 1 . Usage :

∗ r b d c t l −hTh i s h e l p .

∗ r b d c t l −v r o l l b a c k d e v i c eD r i v e r ’ s v e r s i o n .

∗ r b d c t l − i r o l l b a c k d e v i c eDevice ’ s i n f o .

∗ r b d c t l −c − i o r i g i n a l d e v i c e −o w r i t e d e v i c er o l l b a c k d e v i c e

C r e a t e < r o l l b a c k d e v i c e > wi th <o r i g i n a l d e v i c e > as i n p u tand <w r i t e d e v i c e > as s u p p o r t s t o r a g e .

∗ r b d c t l −d r o l l b a c k d e v i c eD e l e t e p r e v i o u s l y c r e a t e d < r o l l b a c k d e v i c e >.

∗ r b d c t l −0 [− l w a r n f r e e ] r o l l b a c k d e v i c eR e s e t ( s t o p / run ) p r e v i o u s l y s t a r t e d d e v i c e

< r o l l b a c k d e v i c e >.

∗ r b d c t l −r [− l w a r n f r e e ] r o l l b a c k d e v i c eRun p r e v i o u s l y c r e a t e d < r o l l b a c k d e v i c e >.

∗ r b d c t l −s r o l l b a c k d e v i c eStop p r e v i o u s l y s t a r t e d < r o l l b a c k d e v i c e >.

∗ r b d c t l −y r o l l b a c k d e v i c eSync p r e v i o u s l y s t a r t e d < r o l l b a c k d e v i c e >.

NOTES:The d e v i c e w i l l warn t h e u s e r when t h e p e r c e n t a g e o f f r e e

b l o c k s used f o r mapping i s l e s s t h a n <w a r n f r e e >. V a l i dv a l u e s f o r <w a r n f r e e >: 1 − 9 9 . D e f a u l t : 1 5 .

Algunos detalles:

1. Un parametro obligatorio, siempre que se quiere operar con un dispositivo, es laruta a ese dispositivo, normalmente /dev/rbdX, donde X es un numero.

2. La aplicacion informa siempre al usuario en ingles. Se hace por coherencia conel modulo, puesto que el nucleo, al no tener soporte para varios idiomas, informatambien siempre en ingles.

101


3. El modo recomendado de operacion es: proteger binarios y bibliotecas dejando unaparticion para datos, por ejemplo /home. De esta forma, al apagar siempre se per-deran las modificaciones realizadas fuera de esa particion. En el caso de que sequiera actualizar el sistema, sera necesario no montar en el dispositivo virtual losdirectorios que contienen los ficheros que van a ser actualizados o, de hacerlo, sin-cronizar despues los cambios.

A.3.2.1. Create

Mediante el parametro “-c” se crea realmente el dispositivo que hasta ahora solo erauna forma de enlazar con el controlador. Es necesario indicar un soporte que sera utilizadocomo dispositivo de lecturas y otro que se encargara de las escrituras.

Listado A.4: rbdctl: uso del parametro “-c”.$ r b d c t l −c − i / dev / hdb1 −o / dev / hdc / dev / rbd0F i l e s y s t e m d e t e c t e d : Ext2 / Ext3 .T r y i ng t o c r e a t e d e v i c e / dev / rbd0 :

O r i g i n a l d e v i c e : / dev / hdb1Wri t e d e v i c e : / dev / hdcB l o c k s i z e : 2048 b y t e s .S e c t o r 0 : 2

Device c r e a t e d s u c c e s s f u l l y .

A.3.2.2. Run

Con el parametro “-r” se pone en marcha el dispositivo creado previamente. A partirde ahora, podra ser montado o utilizado como se desee, ya que todas las lecturas de rbd0seran redirigidas a hdb1 y las modificaciones y lecturas de datos modificados iran a hdc.

Con el parametro opcional “-l” se puede cambiar el porcentaje mınimo de bloqueslibres que debe haber antes de avisar al usuario.

Listado A.5: rbdctl: uso del parametro “-r”.$ r b d c t l −r − l 30 / dev / rbd0Warn when t h e p e r c e n t a g e o f f r e e b l o c k s used f o r mapping i s l e s s

t h a n : 30 %.

A.3.2.3. Info

Siempre se puede obtener informacion del dispositivo con el parametro “-i”. Depen-diendo del estado en que se encuentre, la informacion sera mayor o menor. Por ejemplo,si solo esta creado no aparecera informacion relativa a la cantidad de bloques libres o a lamemoria ocupada.

102

A.3 Aplicacion de control

Listado A.6: rbdctl: uso del parametro “-i”.$ r b d c t l − i / dev / rbd0Device / dev / rbd0 (RUNNING) :

||−−− O r i g i n a l d e v i c e : / dev / hdb1| || |−−− S e c t o r s p e r b l o c k : 4 .| || |−−− S e c t o r 0 : 2 .||−−− Wri te d e v i c e : / dev / hdc| || |−−− Warn / F ree : 30 % / 100 %.| || |−−− Amount o f f r e e b l o c k s : PLENTY .||−−− Memory ( o c u p p i e d / max ) : 0 KiB / 192 KiB .

A.3.2.4. Stop

Una vez se ha terminado de utilizar el dispositivo, o si se desea desechar las escrituras,se usa el parametro “-s”. Es necesario este paso previo antes de proceder a eliminar deltodo el dispositivo.

Listado A.7: rbdctl: uso del parametro “-s”.$ r b d c t l −s / dev / rbd0

A.3.2.5. Delete

Para eliminar completamente el dispositivo virtual del sistema es necesario utilizar elparametro “-d”.

Listado A.8: rbdctl: uso del parametro “-d”.$ r b d c t l −d / dev / rbd0

A.3.2.6. Reset

Si solo se quiere desechar los cambios, se puede resumir el par de pasos Stop y Runmediante este comando, indicado por el parametro “-0”. Como subrepticiamente se eje-cuta el comando Run, es posible volver a indicar, mediante el parametro opcional “-l”, elporcentaje mınimo de bloques libres que debe haber antes de avisar al usuario.

103


Listado A.9: rbdctl: uso del parametro “-0”.$ r b d c t l −0 − l 30 / dev / rbd0Warn when t h e p e r c e n t a g e o f f r e e b l o c k s used f o r mapping i s l e s s

t h a n : 30 %.

A.3.2.7. Sync

Si no se quieren desechar los cambios, es decir, se desea fusionar el contenido alma-cenado en el dispositivo de escrituras con el que hay en el de lecturas, se debe utilizarel parametro “-y”. Antes de realizar esta operacion, es muy importante desmontar el dis-positivo virtual o montarlo con el modo de solo lectura. Ası, antes de que se realice lasincronizacion, el sistema de ficheros, visto desde el dispositivo virtual, tendra un estadoconsistente. Aun ası, la aplicacion le recordara este detalle al usuario y pedira su confir-macion antes de proceder.

Listado A.10: rbdctl: uso del parametro “-y”.$ r b d c t l −y / dev / rbd0Be s u r e t h a t t h e d e v i c e / dev / rbd0 i s mounted as read−on ly o r n o t

mounted a t a l l . Dur ing t h e sync , no w r i t i n g s w i l l bea l l o w e d . Do you want t o c o n t i n u e ? ( yes / no ) yes

Sync ing d e v i c e s . . . ( t h i s o p e r a t i o n w i l l move a l l t h e wro te d a t afrom t h e w r i t e d e v i c e t o t h e o r i g i n a l one , p l e a s e bep a t i e n t ) .

A.3.2.8. Version

Utilizando el parametro “-v” se obtiene la version del controlador y la de la aplicacionde control.

Listado A.11: rbdctl: uso del parametro “-v”.$ r b d c t l −v / dev / rbd0r b d c t l 0 . 1 − D r i v e r ’ s v e r s i o n : 0 . 1 .

A.4. Script de pruebasEl script test/ptest.sh tiene como fin probar el correcto funcionamiento del proyecto.

Recibe tres parametros: el dispositivo de lecturas, el de escrituras y el punto de montajeque podra usar para trabajar.

Su labor, a grandes rasgos, consiste en descargar, mediante la herramienta wget, unfichero que contiene los fuentes de la biblioteca OpenSSL y probar a descomprimirlovarias veces sobre un soporte protegido con la solucion. Para estresar un poco mas lasolucion, la particion utilizada como dispositivo de lecturas es formateada con variossistemas de ficheros (Ext2, Ext3, ReiserFS y JFS), utilizando distintos tamanos de bloque

104

A.4 Script de pruebas

(1024, 2048 y 40962) antes de proceder a operar sobre ella. En el momento que se detectealgun error se detiene el script avisando al usuario.

Para poder probar todos los sistemas de ficheros enumerados es necesario que seencuentren instaladas las aplicaciones encargadas de dar formato: mkfs.ext2, mkfs.ext3,mkfs.reiserfs y mkfs.jfs.

2JFS solo permite un unico tamano de bloque de 4096 bytes.

105

Apendice B

HERRAMIENTAS UTILIZADAS

B.1. Software libre o de codigo abiertoSe ha intentado primar la utilizacion de herramientas de software libre o de codigo

abierto por decision personal. Las herramientas de este estilo utilizadas son:

Debian: se ha elegido esta distribucion Linux para las pruebas en maquinas virtuales.http://www.debian.org/.

DIA: programa utilizado en la creacion de los diagramas que acompanan a este docu-mento.http://www.gnome.org/projects/dia/

Gentoo: es la distribucion Linux donde se ha desarrollado enteramente la solucion.http://www.gentoo.org/

Herramientas de compilacion GNU: para compilar se han utilizado las herramientasclasicas de desarrollo GNU, como son GCC, Make, binutils, etc.http://www.gnu.org/

LATEX: utilizado en la creacion de este documento.http://www.latex-project.org/

QEMU: es un emulador de procesadores de codigo abierto. Se ha utilizado para probary testear de manera controlada los avances en el desarrollo de la solucion.http://bellard.org/qemu/

Vim: no se ha utilizado ningun entorno de desarrollo integrado, sino este clasico editorde texto con capacidades de resaltado de sintaxis, correccion ortografica, etc.http://www.vim.org/

Finalmente, el desarrollo de la solucion se encuentra bajo licencia GPLv2, mientrasque este documento esta disponible mediante una licencia Creative Commons.

107

HERRAMIENTAS UTILIZADAS

B.2. Software privativoHa habido momentos en los que las herramientas del punto anterior no eran suficiente

o carecıan de alguna caracterıstica importante. En esos casos se ha decidido utilizar elsiguiente software privativo:

VMware: es un software de virtualizacion de la empresa VMware. Ha sido la alternativaa QEMU, cuando se han hecho pruebas en la arquitectura AMD64, debido a la pocaestabilidad de QEMU en esa arquitectura.http://www.vmware.com/

108

universidad politecnica de madrid´ -...

Documents