UNIVERSIDAD POLITÉCNICA DE MADRID

Transcripción

1 UNIVERSIDAD POLITÉCNICA DE MADRID FACULTAD DE INFORMÁTICA TRABAJO FIN DE CARRERA Sistema de escrituras volátiles para Linux AUTOR: TUTOR: Rafael Antonio Porras Samaniego Fernando Pérez Costoya

2

3 Esta obra está bajo una licencia Reconocimiento-No comercial-sin obras derivadas 2.5 España de Creative Commons. Para ver una copia de esta licencia, visite o envie una carta a Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA. I

4

5 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

6 Índice general 1. INTRODUCCIÓN Y OBJETIVOS Introducción Estado del arte Software de clonado de disco Restaurar sistema en Windows XP Máquina virtual de sistema con instantáneas de estado Instantáneas y clones en ZFS BranchFS en SkyOS Software de protección Hardware de protección Objetivos Estructura del libro PLANTEAMIENTO DE SOLUCIONES Introducción Propuestas Modificación de un sistema de ficheros Adaptar el sistema de memoria virtual Intercepción de la capa de E/S de bloques Dispositivo virtual CONCEPTOS PRELIMINARES Introducción Linux Manejo de la memoria Informar al usuario Gestión de errores Concurrencia y condiciones de carrera Introducción Semáforos Spin lock IV

7 4. DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN Introducción Creación del dispositivo virtual Estructura de módulo Registro del dispositivo Disco virtual Cola de peticiones Control de entrada y salida Miscelánea Lógica del mapeo Tratamiento clásico de una petición E/S Tratamiento de la petición de E/S por parte de la solución Modificación y/o fragmentación de una petición BIO CARACTERÍSTICAS OPCIONALES Introducción Consumo de memoria Sincronización de dispositivos Estadísticas de acceso al dispositivo Estructura del fichero diskstats Estructura disk stats Macro disk stat add Macro disk stat inc Soporte para blktrace Caché de objetos Utilización de macros de Linux Integración con el sistema de compilación del núcleo Linux CONCLUSIONES Y FUTURAS LÍNEAS Conclusiones Futuras líneas Estadísticas BIBLIOGRAFÍA 97 A. INSTRUCCIONES DE COMPILACIÓN Y USO 99 A.1. Introducción A.2. Dispositivo virtual A.2.1. Compilación e instalación A.2.2. Inicialización del módulo A.3. Aplicación de control A.3.1. Compilación e instalación A.3.2. Uso A.4. Script de pruebas V

8 B. HERRAMIENTAS UTILIZADAS 107 B.1. Software libre o de código abierto B.2. Software privativo VI

9 Índice de figuras 1.1. Norton Ghost Restaurar sistema en Windows XP Gestión de instantáneas en VMware Workstation HDGUARD en Windows XP Tarjeta PCI WinSchool Safety Card Diagrama de sistemas de Linux Estructura de una partición Ext2 y de su grupo de bloques Modificación propuesta: Ext Modificación propuesta: Ext2 y el sistema de memoria virtual Traducción de una dirección de memoria virtual a una dirección física Relación entre los bloques, las páginas, el soporte y los buffer head Modificación propuesta: Ext2 y la etapa de E/S Modificación propuesta: dispositivo virtual Transición entre estados del controlador Bloques, segmentos y páginas Relación de los distintos BIO con sus segmentos y bloques Ejemplo de subzona: bloques NO MAPEADO y bloques mapeados Ejemplo de subzona: bloques mapeados consecutivos y no consecutivos Fragmentación de un BIO en tres minibio Ejemplo de BIO con tres segmentos que ocupan cada uno una página completamente y que serán utilizados en la transferencia Creación de un BIO que requiere de un segmento y medio de los disponibles Creación de un BIO que requiere de medio segmento de los disponibles Creación de un BIO que requiere del último segmento disponible Mapa con una estructura de dos niveles Gráfica correspondiente a la evolución de las líneas de código de la solución. 94 VII

10

11 Índice de listados 3.1. Asignar y liberar memoria Niveles de alerta para printk Ejemplo sin goto Ejemplo con goto Operar con semáforos Operar con semáforos lectura/escritura Operar con spinlock Operar con spinlock lectura/escritura Esqueleto de código del módulo Ejemplo de modinfo Extracto del directorio /dev Función de registro del dispositivo de bloques Registro del dispositivo de bloques Estructura gendisk Plantilla de operaciones de un dispositivo de bloques Creación y destrucción del dispositivo Método open del dispositivo Método release del dispositivo Método getgeo del dispositivo Gestión de colas de dispositivo Creación de una cola de dispositivo Página ioctl del manual del programador de Linux Función ioctl Comandos ioctl definidos en el fichero map.h Macros para la creación de ioctl Acceso a memoria del espacio del usuario Ioctl RBD INFO Ioctl RBD CREATE Ioctl RBD DELETE Ioctl RBD RUN Ioctl RBD STOP Ioctl RBD RESET Ioctl RBD SYNC Ioctl RBD VERSION Comprobación de permisos IX

12 4.28. Estructura con información de la instancia del dispositivo Estructura de un bio vec Estructura BIO Estructura que relaciona un BIO con varios minibio Manipulación de estructuras BIO Ejemplo de fichero /proc/diskstats Ejemplo de fichero /sys/block/hda/stat Ejemplo de fichero /sys/block/hda/hda1/stat Estructura disk stats Función disk stat add Actualización de estadísticas Función disk stat inc Funciones de blktrace Uso de blk add trace remap Uso de blk add trace bio Gestión de la caché de BIO Gestión de la caché de objetos Macro bio data dir Macros bio iovec dix y bio sectors Macros likely y unlikely Ejemplo de uso de la macro unlikely Fichero Kconfig del controlador Fichero Makefile del controlador A.1. Aplicar el parche a los fuentes de Linux A.2. Dispositivos creados en /dev/ usando el valor 3 con el parámetro max rbd. 100 A.3. Salida por pantalla de rbdctl sin opciones A.4. rbdctl: uso del parámetro -c A.5. rbdctl: uso del parámetro -r A.6. rbdctl: uso del parámetro -i A.7. rbdctl: uso del parámetro -s A.8. rbdctl: uso del parámetro -d A.9. rbdctl: uso del parámetro A.10.rbdctl: uso del parámetro -y A.11.rbdctl: uso del parámetro -v X

13 Capítulo 1 INTRODUCCIÓN Y OBJETIVOS 1.1. Introducción En 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 estabilidad del equipo, reduciendo incluso su rendimiento. Otras veces, los usuarios ni siquiera son conscientes de que han realizado acciones que han puesto en peligro su equipo. La siguiente lista contiene una serie de ejemplos que ilustrarán mejor estas situaciones: Instalación y/o desinstalación de software: el continuo instalar y desinstalar software, sobre todo para necesidades puntuales, puede generar un sistema bastante pesado por la cantidad de ficheros olvidados por toda la unidad, entradas inútiles en el registro del sistema, etc. Actualización del software existente: las actualizaciones pueden fallar durante el proceso dejando la aplicación que se actualizaba en un estado inconsistente. Puede ser incluso necesaria una reinstalación de la misma. Si la actualización que falla es del Sistema Operativo (a partir de ahora, SO), la única solución podría ser reinstalarlo. Cambios en la configuración del software: las modificaciones en los ficheros de configuración de cualquier software ya sea para modificar su comportamiento o para afinar su rendimiento, si no se tiene cuidado, pueden dar lugar a que el mismo deje de funcionar correctamente. Y no siempre es fácil recordar todos los cambios efectuados o hacer copias de los ficheros involucrados, siendo necesario restaurar una copia de seguridad. Borrado accidental de archivos: al administrar un equipo es posible equivocarse y eliminar ficheros vitales del sistema o de una aplicación, dejando el equipo inutilizado para el trabajo. Es necesario restaurar una copia de seguridad. Formateo accidental de un sistema de ficheros: bastante menos probable que el caso anterior, pero aun así factible. La única solución es restaurar una copia de seguridad. 1

14 INTRODUCCIÓN Y OBJETIVOS Corrupción del sistema de ficheros: un apagón, si no se dispone de un sistema de alimentación ininterrumpida, o un fallo hardware, pueden dejar al SO en un estado inconsistente que no permita su reinicio. Dependiendo de si el fallo afecta al SO o a las aplicaciones, podría ser necesario reinstalar el SO o las aplicaciones fallidas, respectivamente. Infección por virus, spyware 1, adware 2 y demás malware 3 : a causa de las vulnerabilidades del software, es probable que un equipo sea invadido por este tipo de software. Eliminarlos puede ser una tarea ardua y a veces es más rápido partir de una copia de seguridad que contenga un sistema limpio. Cualquiera de estos casos supondría una pérdida de tiempo y recursos muy valiosos para cualquier organización, sea una empresa u otro tipo de institución. Incluso para un usuario normal, en el entorno de su hogar, sería una molestia y un inconveniente perder datos o tener que reinstalar su equipo. Por tanto, el objetivo de este trabajo es paliar en la medida de lo posible estos problemas, evitando completamente sus consecuencias cuando sea posible. Para ello, se modificará el SO Linux para que todas las operaciones realizadas sobre una partición montada no sean permanentes. Cuando se reinicie el equipo, los cambios desaparecerán pero mientras el usuario trabaje, los cambios deberán almacenarse como se haría en un sistema normal. También será posible deshacer las escrituras inmediatamente por medio de una aplicación especial sin tener que reiniciar. El alcance de este Trabajo Fin de Carrera (TFC) y los objetivos que debe cumplir se establecerán en el punto 1.3, después de analizar las soluciones disponibles actualmente, aunque sean para otras plataformas distintas de Linux. Así, analizando los pros y los contras de cada solución, será más fácil elaborar una lista de requisitos mínimos que el TFC debe cumplir además de añadir otros de tipo secundario u opcional. Las ventajas de un desarrollo de este tipo son evidentes. A partir de la lista de casos anteriores se puede deducir que una vuelta al estado anterior de la partición, esto es, al momento en el que se inició el equipo para trabajar, solucionaría casi todos los problemas enumerados. Además, hay ciertas ventajas derivadas de este sistema. He aquí algunos ejemplos: Los cibercafés 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 tener un entorno limpio, como recién instalado, listo para el siguiente usuario. Ferias y exposiciones donde diversos participantes muestran software a potenciales clientes pueden realizar demostraciones como siempre. Una vez se quiera volver a acondicionar el equipo para nuevas demostraciones basta con reiniciar el equipo 1 Un programa espía o spyware es una aplicación que recopila información sobre una persona u organización sin su conocimiento. 2 Un programa adware es cualquier programa que automáticamente ejecuta, muestra o baja publicidad al computador después de instalado el programa o mientras se está utilizando la aplicación. 3 Malicious software o software malicioso es un software que tiene como objetivo infiltrarse en o dañar un ordenador sin el conocimiento de su dueño y con finalidades muy diversas. 2

15 1.2 Estado del arte y este volverá a su estado original. Incluso se puede dejar al cliente que pruebe el software con la certeza de que será muy simple restaurar el equipo. El caso de máquinas de prácticas para alumnos sería bastante similar al anterior. Incluso se podría permitir la instalación de software por parte del alumno, ya que una vez que este termine de usar el equipo, el sistema quedaría listo para volver a usarse. Este caso es bastante parecido al de empresas que dan soporte y mantenimiento de equipos desplegados en las instalaciones de otras empresas Estado del arte Una 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 mostrar sus beneficios y sus inconvenientes. Se comenzará con aquellos productos más genéricos o cuyo uso principal no se corresponda con las situaciones anteriormente expuestas y se terminará por las mejores soluciones encontradas, siendo la última una solución hardware Software de clonado de disco Figura 1.1: Norton Ghost Este tipo de software es utilizado para clonar discos duros. La copia puede ser sector a sector, de forma que se clone completamente la partición, sin variar su tamaño, o 3

16 INTRODUCCIÓN Y OBJETIVOS transfiriendo el contenido del sistema de ficheros a otro sistema de ficheros en otro disco, incluso de tamaño distinto. Esta última característica requiere de un software capaz de trabajar con los sistemas de ficheros más comunes como son FAT, NTFS, Ext2 y Ext3. El soporte clonado puede ser transferido a otro disco, en la misma máquina o vía red, además de almacenarse en otro dispositivo para un uso posterior. Algunos software permiten incluso editar esa imagen y así modificar los ficheros o directorios contenidos. Norton Ghost (ver figura 1.1) es el software de este tipo más conocido y fue el primero en abrir mercado para el software de clonado de disco. Hay más productos de otros fabricantes, como PartImage y Paragon Drive Backup, para los sistemas operativos más usados. A favor: Permite restaurar el soporte a partir de una imagen limpia cómodamente, sobrescribiendo datos y metadatos 4. A veces se puede planificar la restauración para que se realice en un momento determinado. Ese momento puede ser en una hora determinada o cuando el usuario cierre la sesión. Este tipo de software suele tener un modo de funcionamiento autónomo con el 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 salvaguardar hay que actualizar la imagen. El tiempo de espera para restaurar una imagen depende de si siempre restaura la imagen sin importar lo que se haya modificado, o de si tiene en cuenta los ficheros y directorios modificados para restaurar únicamente estos Restaurar sistema en Windows XP Restaurar 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 atrás se consigue mediante la restauración de los ficheros, programas instalados, claves de registro, etc. que hubiera en el momento en el que se realizó la instantánea del equipo o punto de restauración. Para que los puntos de restauración no ocupen el soporte completamente, se limita el espacio disponible para los mismos hasta el 13 % del total del soporte. Si ese espacio quedara ocupado completamente, el sistema iría eliminando automáticamente los puntos de restauración más viejos. datos. 4 Los metadatos son, literalmente, datos acerca de los datos y aportan información o ayudan a ubicar 4

17 1.2 Estado del arte Figura 1.2: Restaurar sistema en Windows XP. A favor: Su integración con el sistema operativo hace que sea muy fácil de usar. Guarda puntos de restauración automáticamente ante cambios críticos en el sistema operativo, como son las actualizaciones mediante Windows Update 5, la instalación de nuevo software o de controladores no firmados digitalmente, cada cierto tiempo de uso, etc. además de a petición del usuario. En contra: Esta solución sólo funciona en las plataformas Windows antes indicadas. En Windows XP depende del sistema operativo, de forma que si este es incapaz de arrancar no se podrá restaurar el sistema. Si no hay espacio libre no se crean los puntos de restauración automáticos, y será posible el caso de que un usuario descubra que no puede restaurar el sistema porque no se ha podido crear ningún punto de restauración. 5 Es un servicio que da Microsoft a sus usuarios de Windows. Permite aplicar parches de seguridad al sistema operativo y a sus productos de forma automática. 5

18 INTRODUCCIÓN Y OBJETIVOS No protege íntegramente el volumen, sino aquellos ficheros y directorios pertenecientes al perfil 6 de los usuarios, además de contenido crítico del sistema Máquina virtual de sistema con instantáneas de estado Figura 1.3: Gestión de instantáneas en VMware Workstation. El software de virtualización multiplexa el acceso al hardware de forma que distintas máquinas virtuales pueden disponer de él como si fueran las únicas con acceso al mismo. El hardware virtualizado es mostrado al usuario como una máquina virtual capaz de ejecutar aplicaciones o sistemas operativos como si fuese la máquina real. Normalmente hay cierta penalización en el rendimiento, pues sólo hay un hardware (entiéndase como un conjunto de piezas hardware que constituyen el equipo) y debe planificarse el acceso de varias máquinas a un mismo recurso. Algunos fabricantes de procesadores como Intel o AMD han añadido extensiones a sus procesadores para así facilitar el trabajo con este tipo de software y aumentar el rendimiento. El fabricante por excelencia es VMware 7 con su software VMware Workstation (ver figura 1.3), aunque hay más soluciones de otros fabricantes como Parallels Workstation o 6 Es un conjunto de ficheros y directorios que almacenan documentos y ajustes del sistema para ese usuario en particular

19 1.2 Estado del arte QEMU 8. El usuario puede crear máquinas virtuales con las que trabajar y, antes de realizar algún cambio crítico en alguno de los soportes, tomar una foto o instantánea de la máquina. Si necesitase volver a un punto anterior, bastaría con restaurar la máquina virtual partiendo de la instantánea. Se pueden realizar varias instantáneas e incluso volver a alguna de ellas y crear otra más sin sobrescribir las posteriores de forma que, más que una secuencia lineal de estados de la máquina, se obtenga un árbol de estados, cada uno con variaciones sobre la máquina virtual original. A favor: Facilidad para crear y gestionar las instantáneas además de poder guardar tantas como se deseen. Al poder guardar el estado completo de la máquina, se puede volver no sólo al estado original del dispositivo que sufrió la modificación que se quiere deshacer, sino al mismo instante de la operación, restaurando además las aplicaciones que estuvieran funcionando con los datos que manejaran en ese momento. Se pueden eliminar las instantáneas intermedias si se desea mantener los cambios. En contra: El rendimiento se ve penalizado con respecto al hardware real. Estas máquinas no pueden virtualizar todo tipo de hardware por ello, si el software de virtualización no da soporte para un hardware específico, este no estará disponible dentro de la máquina Instantáneas y clones en ZFS ZFS es un sistema de ficheros diseñado por Sun Microsystems 9 para su sistema operativo Solaris. El significado de las iniciales proviene del inglés Zettabyte File System. Publicado a finales del 2005, fue desarrollado para utilizarse en sistemas de almacenamiento de alta capacidad. Posee ciertas características singulares como son la comprobación y reparación de datos al vuelo y la posibilidad de guardar instantáneas y clones de cada fichero. Una instantánea es una copia de sólo lectura de un fichero situado en un volumen ZFS. Se crea al momento e, inicialmente, no consume espacio adicional. A medida que el fichero original cambie, la instantánea irá ocupando espacio para poder hacer referencia al contenido original. Cuando se quiera recuperar el contenido del fichero, tal y como fue capturado por la instantánea, bastará con indicar al sistema de ficheros que revierta el estado del fichero usando la información de la instantánea. 8 QEMU es un emulador de procesadores basado en la traducción dinámica de binarios (conversión del código binario de la arquitectura fuente en código entendible por la arquitectura huésped)

20 INTRODUCCIÓN Y OBJETIVOS Un clon es una instantánea que puede ser modificada, de forma que los cambios desarrollados en el clon pueden ser trasladados, una vez se esté seguro de su contenido, al fichero original del que se partió. A favor: Permite tener múltiples instantáneas de un mismo fichero y es posible regresar a cada una de ellas. Las copias pueden ser modificadas y, dependiendo del resultado, volver al fichero capturado en la instantánea o sobrescribirlo con la copia modificada. En contra: Al generar una instantánea de un fichero, es probable que se produzca cierta fragmentación. Si la fragmentación aumentase, por ejemplo, al realizar varias instantáneas de un mismo fichero, podría verse perjudicado el rendimiento. El usuario tiene que haber tomado una instantánea antes de proceder a realizar algún cambio crítico. Ante cambios inesperados, como un virus o un borrado accidental, el usuario se encuentra desamparado. Al ser una característica de ZFS, solo podrá ser utilizada en aquellos sistemas operativos donde, además de encontrarse implementado este sistema de ficheros, se haya implementado también esta avanzada característica BranchFS en SkyOS SkyOS 10 es un sistema operativo con interfaz gráfica, en constante desarrollo, escrito para la arquitectura IA-32. Nació como un experimento en el desarrollo de sistemas operativos por parte de su autor, Robert Szeleney, mientras estudiaba en la universidad. Entre sus características principales cabe destacar: Multitarea apropiativa además de características básicas como protección de procesos e hilos y gestión de memoria virtual. Soporte para VESA desde el núcleo, permitiendo una interfaz gráfica nada más iniciarse el SO. Soporte para SMP 11 e Hyper-threading 12. Sistema de ficheros propio, SkyFS, derivado de OpenBFS Multiprocesamiento simétrico, del inglés Symmetric MultiProcessing, es una arquitectura de computadores donde dos o más procesadores idénticos se hallan conectados a la misma memoria principal. 12 Es una tecnología propietaria de Intel utilizada para mejorar la paralelización de los cálculos que se realizan en un PC mediante la ejecución de múltiples hilos independientes. 8

21 1.2 Estado del arte Además, dispone de un sistema de ficheros virtual denominado BranchFS capaz de crear una rama 13 de un sistema de ficheros cualquiera. Al trabajar sobre esta rama, se tiene acceso al sistema de ficheros del que se partió, pero cualquier cambio que se realice no afectará al original. Al crear la rama, debe indicarse el soporte que almacenará los cambios del sistema de ficheros. A favor: Al ser virtual, se pueden crear ramas del sistema de ficheros de un DVD de forma que, aparentemente, se pueda escribir sobre el mismo. Permite utilizar, como soporte donde guardar los cambios, un disco de memoria, así las operaciones sobre los ficheros modificados serán más rápidas. Los cambios permanecen entre reinicios si el soporte es persistente y no se borra su contenido. En contra: Se puede encontrar exclusivamente en SkyOS. Las modificaciones no se pueden combinar con el sistema original si interesara conservarlas. A petición del usuario se crean las ramas. Si hay algún cambio inesperado que altere el sistema y no se está trabajando en un rama, no se podrán deshacer los cambios Software de protección HDGUARD 14 (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 mismas son desviadas a una partición no utilizada o a un fichero propio. Estas modificaciones perdurarán hasta que el usuario decida eliminarlas, o podrán ser aceptadas e integradas con el resto de datos del soporte. Otro ejemplo de este tipo de software es DeepFreeze 15 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 partición no usada o en un fichero de intercambio. 13 Entiéndase rama como una copia que deriva de un original al que se halla ligado

22 INTRODUCCIÓN Y OBJETIVOS Figura 1.4: HDGUARD en Windows XP. En contra: No puede guardar diferentes estados o puntos de restauración. Si se quiere deshacer los cambios de una unidad, aunque no sea la de sistema, es necesario reiniciar el equipo Hardware de protección Existen soluciones hardware equivalentes a las soluciones software expuestas en el apartado anterior. Un ejemplo de ellas son las tarjetas WinSchool Safety Card (ver figura 1.5) o Hard Drive Recovery Card. A favor: Puede proteger incluso la configuración de la BIOS 16. 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 restauración. 16 BIOS, del inglés Basic Input/Output System, es un microcódigo que se encarga de identificar e inicializar los componentes hardware del equipo. De esta forma prepara el equipo para que otro software pueda tomar el control del mismo. 10

23 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 protección de la BIOS, no ofrece ningún beneficio adicional por ser una pieza hardware. Figura 1.5: Tarjeta PCI WinSchool Safety Card Objetivos El objetivo del TFC es desarrollar una solución para los problemas dados en la introducción, pero siempre pensando que su sistema operativo destino es Linux. La elección de Linux viene dada porque está disponible su código fuente y se puede modificar a voluntad para añadirle todas aquellas capacidades nuevas que se deseen. Cierto es que se podría desarrollar una solución para Windows mediante el API 17, ofrecida por el DDK 18 de Microsoft, pero, como se ha indicado en el punto anterior, ya hay varias soluciones para esa plataforma. El funcionamiento deseado es el siguiente: dada una partición cualquiera formateada con cierto sistema de ficheros (a partir de ahora, SF) y lista para usar, cualquier acceso de escritura a esta partición no modificará realmente la misma, aunque sí deberá reflejar esos cambios como si se hubieran producido. En cambio, la lectura de datos de esa partición deberá devolver los datos que se hallaran en ella o, si hipotéticamente se hubieran modificado, los datos actualizados. La escrituras deben, por tanto, redirigirse a los huecos libres de la partición sin sobrescribir datos y/o metadatos o escribirlos directamente en otro soporte. No es aceptable dejar las escrituras simplemente en memoria, sin respaldo en otro soporte, por el gran consumo de memoria del espacio del núcleo que podría llegar a producirse. 17 Un API (del inglés Application Programming Interface - Interfaz de Programación de Aplicaciones) es el conjunto de funciones y procedimientos (o métodos si se refiere a programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. 18 Un DDK (del inglés Driver Development Kit - Kit de Desarrollo de Controladores) es un conjunto de herramientas que permite el desarrollo de controladores de dispositivo para una cierta plataforma. 11

24 INTRODUCCIÓN Y OBJETIVOS El resultado final esperado es que, aun habiendo escrito, modificado y/o borrado datos de la partición, ésta, una vez se decida deshacer los cambios, vuelva al estado que tenía al empezar a trabajar con ella. Concretamente, desde el punto de vista del usuario, este no notará modificación alguna en los datos; desde el punto de vista del SF, además, los metadatos estarán intactos. Es decir, se puede restaurar la partición al punto en el que se hallaba al empezar a trabajar con ella, obviando datos posiblemente escritos por la solución en aquellas zonas no usadas (que no ignoradas) por el SF. Nótese que, aunque esto se asemeje a una especie de puntos de guardado de la partición, sólo se podrá retornar al punto inicial. No habrá puntos intermedios: todo o nada. Lo de todo viene porque, como objetivo opcional, se propone la posibilidad de sincronizar la partición con los datos que deberían haberse escrito. Este proceso de sincronización deberá tomar los datos que el SF da por escritos en la partición y escribirlos realmente en aquellas posiciones que el SF indicó en su momento. Además, los cambios se desharán automáticamente si se reinicia el equipo. Realmente no se deshará nada, ya que, al reiniciar y volver a montar la partición, los cambios no aparecerán, porque nunca fueron fusionados con el resto de datos y metadatos del SF de la partición. Idealmente, la solución no debería estar atada a ningún sistema de ficheros en particular, pero, si esto no fuera posible, se dará prioridad a aquella solución que permita el uso de los SF más comunes como son Extended 2, Extended 3 y ReiserFS. También es necesario que no requiera de hardware adicional, es decir, que la solución sea eminentemente software y funcione en un equipo normal. Parece obvio pensar que una solución que dé respuesta a todas estas premisas debe separarse en dos partes: 1. Un controlador o driver que se encargue de tratar las operaciones de acceso a la partición. La necesidad del controlador surge para poder acceder directamente al dispositivo de bloques que se protege y así controlar lo que el SF le envíe. 2. Una aplicación que se encargue de hacer llegar al controlador las necesidades del usuario. Es decir, qué partición se quiere proteger, si se quiere deshacer las escrituras, etc. Otro objetivo opcional será conseguir que la solución funcione con la partición que se usará como directorio raíz, es decir, el primer directorio de la jerarquía de directorios del sistema. Se marca como objetivo porque, al contrario que otras particiones, ésta se monta la primera y suele tener más restricciones de uso. El problema es el siguiente: la aplicación de control se encuentra en la partición raíz que se quiere proteger. Si se monta la partición para acceder a la herramienta, ya no se podrá desmontar esa partición. Si no se puede desmontar, cómo puede ser protegida? Si no se monta, cómo se accede a la herramienta? Cómo podría resolverse este círculo vicioso? La solución a este problema será un objetivo secundario. Es necesario comentar que, aunque se hable constantemente de una partición, esto no tiene por qué ser así. Es decir, la solución se centrará en los dispositivos de bloques, ya sea la propia partición, un disco entero formateado para su uso, o un fichero simulando ser un dispositivo de bloques por medio del dispositivo loop. 12

25 1.4 Estructura del libro Dependiendo de la solución que se desarrolle, es posible que se añadan nuevos objetivos adicionales. Estos objetivos deberán indicarse cuando se explique detalladamente la solución elegida finalmente de entre varias propuestas. Esta discusión se desarrollará en el capítulo 2. Por motivos de seguridad, la solución sólo podrá ser gestionada por el usuario root 19. Además, la solución será inútil ante cambios directos a la partición (dispositivo /dev/xxx correspondiente) o ante cambios realizados fuera del sistema como son desde Windows u otras versiones de Linux sin la solución habilitada, por ejemplo, un LiveCD 20. Finalmente, la solución final será publicada bajo licencia GPL 21 y exclusivamente la versión Estructura del libro El libro está estructurado por capítulos y de la siguiente forma: Introducción y objetivos: es el capítulo actual. Trata, como se ha visto, de las motivaciones del proyecto. Además, se ha detallado una lista de soluciones encontradas para poder definir con conocimiento de causa qué es lo que se quiere obtener. Finalmente, se ha propuesto una serie de objetivos que deberá cumplir al final la solución desarrollada. Planteamiento de soluciones: enumerará distintas propuestas realizadas, con sus pros y sus contras, y con un cierto nivel de detalle para elegir finalmente la mejor de ellas. Conceptos preliminares: describirá y explicará conceptos básicos del núcleo Linux, sobre todo aquellos que han sido utilizados en el desarrollo de la solución. Desarrollo e implementación de la solución: mostrará con sumo detalle la solución escogida y todo el desarrollo realizado hasta su conclusión. A veces se hablará de ciertos subsistemas o componentes de Linux que han sido investigados y utilizados, como por ejemplo la gestión de dispositivos de bloques. También se explicará la lógica implementada para poder atender las peticiones de E/S, además de los problemas encontrados, como son los accesos concurrentes a estructuras. Características opcionales: es el capítulo encargado de explicar aquellos objetivos opcionales desarrollados, como, por ejemplo, la optimización en el consumo de memoria o la integración de la solución con el sistema de compilación de Linux. 19 En sistemas operativos del tipo Unix, root o superusuario es el nombre convencional de la cuenta de usuario que posee todos los derechos en todos los modos (mono o multi usuario). 20 Sistema operativo (normalmente acompañado de un conjunto de aplicaciones) almacenado en un medio extraíble, tradicionalmente un CD o un DVD, que puede ejecutarse desde este sin necesidad de instalarlo en el disco duro de un ordenador, para lo cual usa la memoria RAM como disco duro virtual y el propio medio como sistema de ficheros. 21 Es una licencia creada por la Free Software Foundation a mediados de los 80 y está orientada principalmente a proteger la libre distribución, modificación y uso de software. 13

26 INTRODUCCIÓN Y OBJETIVOS Conclusiones y futuras líneas: aquí se intentará determinar los beneficios de la solución y si cumple con todos los objetivos propuestos o, en el caso de que no fuera así, por qué ha sucedido. Además se dará una breve valoración personal del trabajo desarrollado y un breve vistazo a posibles líneas futuras. Apéndices: los dos apéndices aportarán información sobre otras actividades relacionadas con el proyecto, aunque no directamente. Así, se informará de cómo debe compilarse y usarse el proyecto, de las herramientas utilizadas y de las pruebas desarrolladas. 14

27 Capítulo 2 PLANTEAMIENTO DE SOLUCIONES 2.1. Introducción Como se puede apreciar en la figura 2.1, Linux está estratificado en varias capas y algunos de sus sistemas no sólo prestan servicios a las aplicaciones del usuario sino también a otros sistemas del núcleo. Figura 2.1: Diagrama de sistemas de Linux. En el ejemplo, se observa cómo se ofrecen al usuario el sistema de memoria virtual (en inglés, Virtual Memory Manager o VMM) y el sistema de ficheros (en inglés, Virtual File System o VFS). VFS es una capa de abstracción situada encima de los verdaderos sistemas de ficheros: Ext2, Ext3, ReiserFS, etc. Su misión consiste en proporcionar acceso, de manera uniforme, a los distintos sistemas de ficheros a los que el SO da soporte. Por otro lado, VMM se encarga de la gestión de la memoria y de ofrecerla a las aplicaciones y a los distintos sistemas del núcleo. Ese es el motivo por el que los sistemas de ficheros aparecen representados encima de la capa VMM. 15

28 PLANTEAMIENTO DE SOLUCIONES Debajo de VMM se halla la capa de E/S de bloques (en inglés, Block I/O Layer o BIO), cuya misión es proporcionar acceso a los dispositivos del sistema, como pueden ser discos duros, disquetes y demás dispositivos de bloques. VMM hace uso de esa capa, ya que mucha de la información que se almacena en memoria proviene de los soportes mencionados anteriormente, en su mayoría imágenes ejecutables, bibliotecas o ficheros de datos. Finalmente, BIO se encarga de acceder a los dispositivos mediantes los controladores adecuados, que son quienes, en última instancia, tratan con el hardware. Por ejemplo, para una lectura de un fichero, la petición se traslada mediante llamadas al sistema hasta VFS. Este averigua en qué tipo de sistema de ficheros se halla y procede a trasladar la petición al SF adecuado. El SF localiza en qué disco y en qué sector se encuentra el fichero y procede a leerlo del soporte. Para ello, reserva unas páginas de memoria mediante VMM. A continuación, envía una petición a BIO para que proceda a leer del disco dado y en el sector indicado los bloques que necesite. Esos bloques serán leídos del soporte utilizando el controlador correspondiente a ese disco, y su contenido almacenado en la memoria previamente solicitada. Esta memoria será proporcionada a la aplicación que solicitó los datos para que los utilice convenientemente. En los apartados siguientes se explicarán las propuestas acompañadas de sus beneficios y sus inconvenientes. Tomando la figura de partida, se resaltarán aquellas capas modificadas o, si fuera necesario, aquellos elementos añadidos para conseguir alcanzar la solución Propuestas Modificación de un sistema de ficheros Como solución más inmediata se propone la modificación de un sistema de ficheros de uso mayoritario como, por ejemplo, Extended 2. Extended 2 (también conocido como Ext2) es un sistema de ficheros para Linux desarrollado por Rémy Card como reemplazo de Extended. Al contrario que su sucesor, Extended 3, no posee capacidades de journaling 1. Tolera particiones de hasta 16 TiB, con un tamaño máximo de fichero de 2 TiB y hasta archivos. Ext2 divide el espacio de la partición en bloques del mismo tamaño, agrupando cada bloque varios sectores. Los bloques son, a su vez, asociados en grupos para así intentar reducir la fragmentación de los ficheros, ya que Ext2 intenta que los datos de un fichero estén siempre en el mismo grupo. La figura 2.2 ofrece una vista de la estructura del sistema de ficheros Ext2 en un disco. Dentro de cada grupo hay: Un superbloque: se encarga de almacenar cierta información, como puede ser el tamaño del bloque, el número total de bloques, el número de bloques libres, el número 1 Es un mecanismo por el cual un sistema informático puede implementar transacciones. También se le conoce como registro por diario. 16

29 2.2 Propuestas Figura 2.2: Estructura de una partición Ext2 y de su grupo de bloques. de bloques por grupo, el número de veces que se ha montado la partición, el estado de la misma, etc. Ext2 sólo usa la información contenida en el superbloque del primer grupo (superbloque 0); el resto de superbloques de los demás grupos suelen ser réplicas del superbloque 0 y son utilizados si este último no es consistente. Descriptores de grupo: indican en qué posición del soporte se encuentran el mapa de bits de i-nodos, el mapa de bits de bloques de datos y la tabla de i-nodos de cada grupo. Todos estos datos de cada grupo se hallan contenidos en descriptores de grupo y además todos ellos están replicados en los distintos grupos. Al igual que con el superbloque, sólo se usa el del primer grupo; el resto se utiliza si se detectan problemas de consistencia. Mapa de bits 2 de bloques de datos: indica qué bloques de datos están disponibles y cuáles no. Mapa de bits de los i-nodos: indica qué i-nodos están disponibles y cuáles no. Tabla de i-nodos: almacena los i-nodos, cada uno de los cuales se utiliza para describir un fichero o directorio. Guarda datos tales como el propietario, los permisos, el tamaño y, lo más importante, punteros a los bloques de datos que conforman el contenido del fichero o directorio. Bloques de datos: almacenan el contenido de los ficheros y directorios. Conocida su estructura lógica en el soporte, es necesario enumerar algunas de sus características: Tamaño de bloque variable entre 1024, 2048 y 4096 bytes. El bloque es la unidad mínima de transferencia y suele agrupar varios sectores. Un tamaño de bloque pequeño es ideal para ficheros de pocos bytes, puesto que así se desperdicia menos 2 Un mapa de bits es una estructura que utiliza cada bit para indicar el estado de cada objeto en una colección de ellos. En este caso, indica si está en uso o no el bloque o i-nodo indicado. 17

30 PLANTEAMIENTO DE SOLUCIONES espacio libre por cada bloque no ocupado completamente. Por el contrario, para ficheros grandes es mejor un tamaño de bloque grande también, de forma que se transfieran menos bloques entre el soporte y la memoria. Preasignación de bloques de datos. Se asigna previamente espacio contiguo a los ficheros, es decir, bloques físicamente adyacentes a los datos ya escritos. Así, cuando el tamaño del fichero crezca, se podrán usar esos bloques y paliar los clásicos problemas de fragmentación que suelen reducir el rendimiento del sistema. Admite ficheros inmutables (no pueden ser modificados, borrados o renombrados), ficheros a los que sólo se les puede añadir más datos y enlaces simbólicos. Detecta si no se desmontó correctamente la partición la última vez que se utilizó, forzando un chequeo de comprobación de la misma si fuera necesario. Figura 2.3: Modificación propuesta: Ext2. A partir de la estructura del sistema de ficheros Ext2 es fácil aventurar el contenido de la propuesta: 1. Todo bloque que se modifique y se quiera escribir en la partición, ya sea el superbloque, un mapa de bits o un bloque de datos de un fichero debe escribirse en un bloque de datos libre, donde no sobrescriba información de ningún tipo. 2. Las lecturas se tratarán como siempre ha hecho el sistema de ficheros, con la salvedad de que toda aquella petición de lectura que tenga que ver con bloques reubicados deberá redirigirse a los bloques utilizados en el paso anterior. 3. Nuevas escrituras sobre datos ya reubicados deberán usar los mismos bloques que se utilizaron anteriormente. 18

31 2.2 Propuestas Se usará la palabra reubicar para indicar el procedimiento de redirigir los accesos de escritura a la partición y también a los accesos de lectura de bloques almacenados temporalmente, es decir, aquellos que serán desechados cuando se quiera restaurar el estado original de la partición. Esta propuesta será denominada como Ext2rb. El sufijo rb viene dado por el término rollback y, aunque no sea realmente un sistema con soporte para varias vueltas atrás, sí tiene que ver con el propósito del TFC: deshacer los cambios al terminar de trabajar con el soporte. Las nuevas labores de esta modificación de Ext2 serán las siguientes: 1. Localizar aquellos bloques de datos libres que se puedan usar para almacenar datos modificados o nuevos. 2. Analizar cada petición de lectura o escritura y tratarla adecuadamente: a) Si es una lectura: 1) Si no se realiza sobre datos modificados, devolver los bloques pedidos o acceder a los metadatos correspondientes. 2) Si se realiza sobre datos modificados previamente, redirigir la petición a los bloques donde realmente está la información. b) Si es una escritura: 1) Si es la primera vez que se escribe en esos bloques, utilizar un bloque libre. 2) Si ya se ha reubicado previamente, seguir usando esos mismos bloques. Como pequeña optimización, todos aquellos bloques libres que se asignen a nuevas escrituras no necesitarán ser reubicados pues ya están usando un bloque libre. Por contra, los metadatos, así como los mapas de bits, sí deberán escribirse en algún bloque libre o en uno reubicado previamente, pero siempre sin sobrescribir los originales. Una ventaja adicional es que al utilizar sólo los bloques libres, el verdadero Ext2 podrá seguir usando la partición cuando se quiera trabajar con ella a la manera tradicional. No es necesaria conversión ni modificación alguna de la estructura lógica en el soporte. La desventaja evidente es que esta solución es muy particular y sólo sería válida con particiones que usen Ext2 y, dependiendo del grado de compatibilidad, Ext3. Pero el verdadero problema no es este sino cómo se encuentra implementado Ext2 dentro del código de Linux. Toda la gestión de acceso a bloques del sistema de ficheros está íntimamente ligada al sistema de memoria virtual. Por ejemplo, ante una petición de lectura, se procede a la lectura de los bloques pedidos desde el soporte y se almacenan en memoria, dentro de páginas de memoria. Si se modificaran esos bloques, Ext2 no sería consciente de ello, ni ningún subsistema de Linux le avisaría y, por tanto, no procedería a actualizar el contenido del soporte. Pero, a pesar de ello, el contenido de los bloques sería sincronizado con el del soporte. Cómo es esto posible? La respuesta hay que buscarla en el sistema de memoria virtual ya que, desde el momento que pasan a estar en páginas de memoria esos bloques, 19

32 PLANTEAMIENTO DE SOLUCIONES es este sistema el encargado de actualizar el contenido del soporte si se hiciera alguna modificación a esos bloques. Por tanto, esta solución 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 según se explica en el siguiente apartado. Otro problema es que depende de los bloques libres que existan en el momento de empezar a trabajar con la partición. Si apenas queda espacio libre, sólo se permitirán unas pocas modificaciones hasta agotar el depósito de bloques libres Adaptar el sistema de memoria virtual Para evitar los problemas de la solución anterior se propone realizar unas modificaciones al sistema de memoria virtual. Este sistema, junto con la MMU 3, se encarga de permitir al software que utilice más memoria de la que realmente posee el ordenador. Concretamente, en la arquitectura IA-32, el límite son 4 GiB (2 32 ); para IA-32 con PAE 4, el límite son 64 GiB (2 36 ); en AMD64, aunque el límite teórico es de 16 EiB 5 (2 64 ), las implementaciones actuales sólo alcanzan a manejar 256 TiB 6 (2 48 ). Figura 2.4: Modificación propuesta: Ext2 y el sistema de memoria virtual. Este sistema divide el espacio de memoria en porciones denominadas marcos de página con un tamaño, en IA-32, de 4 KiB 7. Estos marcos se gestionan mediante una estructura conocida como tabla de páginas. La tabla es una estructura multinivel que asocia cada dirección de memoria virtual con un marco de página físico. 3 La unidad de manejo de memoria o Memory Management Unit es la responsable de manejar los accesos a la memoria. Además, se encarga de traducir direcciones virtuales a direcciones físicas, de comprobar los permisos de acceso, del control de la cache, etc. 4 Extensión de direcciones físicas o Physical Address Extension habilita más líneas en el bus de direcciones del procesador pudiendo usar direcciones de 36 bits. 5 Exbibyte (2 60 bytes). 6 Tebibyte (2 40 bytes). 7 En AMD64, el tamaño de página es de 8 KiB. 20

33 2.2 Propuestas El proceso de traducción para IA-32, que se puede observar en la figura 2.5, es el siguiente: Figura 2.5: Traducción de una dirección de memoria virtual a una dirección física. 1. Dada una dirección de memoria virtual, se toman los 10 bits (posiciones 31 a la 22, ambas inclusive) más significativos y se indexa con ellos en la tabla de directorios indicada por el índice de directorios. El resultado de indexar es una dirección de memoria donde se halla una tabla de páginas. 2. Esta última tabla es indexada con los siguientes 10 bits (posiciones 21 a 12, ambas inclusive) más significativos de la dirección dada. El resultado, una vez más, es una dirección de memoria donde se halla el marco de página correspondiente y, por tanto, la página. 3. El desplazamiento dentro de esa página viene dado por los 12 bits restantes y señala la posición real en memoria donde se encuentra el dato solicitado. El directorio de páginas contiene referencias a tablas de páginas. Las tablas de páginas contienen referencias a los marcos de página que, a su vez, contienen las páginas de memoria. Como se explicó en el apartado anterior, los bloques se almacenan en páginas de 4 KiB. Por tanto, el tamaño de bloque de los sistemas de ficheros debe cumplir dos condiciones: 21

34 PLANTEAMIENTO DE SOLUCIONES 1. Debe ser múltiplo de dos y menor o igual que el tamaño de página: 4096 bytes o 4 KiB. 2. Debe ser múltiplo de 512, que es el tamaño estándar en bytes de un sector. Por estas condiciones es por las que en IA-32 sólo se darán por válidos los siguientes tamaños: 512, 1024, 2048 y 4096 bytes. Todo bloque leído, y por tanto almacenado en una página, ya sea ocupándola entera o en parte, tiene además una estructura asignada que se denomina buffer head. Esta estructura indica de qué soporte se obtuvo el bloque y de qué sector. Cuando se modifique ese bloque, y el sistema de memoria virtual lo considere adecuado, se sincronizará el contenido del bloque en la página con el soporte, escribiendo la página en el dispositivo y sector indicados. Obviamente, el tamaño de la escritura es el tamaño del bloque, el cual no varía para esa partición. Figura 2.6: Relación entre los bloques, las páginas, el soporte y los buffer head. La figura 2.6 representa una página de 4 KiB con cuatro bloques de 1 KiB leídos del disco. Cada bloque tiene asociado una estructura buffer head que es la encargada de mantener el vínculo entre los datos en memoria y su ubicación 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 protegido 8, se sustituirá dentro de la estructura buffer head el valor que indica el sector por otro que evite que se sobrescriban datos en el soporte. El sistema de ficheros Ext2rb deberá elaborar una lista de los bloques libres que el sistema de memoria virtual pueda utilizar para escribir aquellos bloques que necesite en el soporte. 8 Protegido significa que no se quiere alterar realmente el contenido del soporte. 22

35 2.2 Propuestas Una desventaja es que se obtiene un sistema que no será portable, ya que modifica el código interno del núcleo que no tiene por qué mantenerse estable entre distintas versiones del mismo, ni podrá ser distribuido como módulo al modificar un sistema del núcleo. Además, es un sistema crítico y bastante complejo, del que dependen muchos otros sistemas y en el que las modificaciones, si no se testean exhaustivamente, pueden dar lugar a corrupciones en todos los dispositivos del sistema. Requiere modificaciones demasiado ambiciosas para lo que se quiere obtener. Esta propuesta, aunque completa la anterior, sigue sin ser suficientemente genérica, pues sólo se podría aplicar a Ext2. Para que funcionase con otros sistemas de ficheros deberían estudiarse su estructura y funcionamiento a fin de poder deducir dónde habría bloques libres que utilizar Intercepción de la capa de E/S de bloques Siguiendo 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 de escribir los bloques al disco (ver figura 2.7). Figura 2.7: Modificación propuesta: Ext2 y la etapa de E/S. Después de que el sistema de memoria decida sincronizar ciertas páginas con sus bloques correspondientes en disco, se genera una estructura con la información necesaria para llevar a cabo esa operación que es enviada a la capa de E/S de bloques, para que escriba realmente los cambios en el dispositivo de bloques adecuado. Modificando esta etapa, se podrían obtener los mismos resultados que con la propuesta combinada anterior, pero sin apenas modificar el código de Ext2 y afectando levemente a un sistema crítico del núcleo. Más detalladamente, el contenido de la propuesta es el siguiente: 1. Al montarse un soporte con Ext2, este deberá indicar, por ejemplo mediante las opciones de montaje, otro soporte que almacenará las escrituras que será denomi- 23

36 PLANTEAMIENTO DE SOLUCIONES nado DE (dispositivo de escrituras). El soporte Ext2, del que solo se realizarán lecturas, será denominado DL (dispositivo de lecturas). Evidentemente, DE también tendrá lecturas de los datos escritos en él. 2. DE será tratado como un vector de bloques del mismo tamaño de bloque que DL, pero completamente vacío. 3. Cualquier petición enviada a la capa de E/S que tenga como destino DL, será interceptada y tratada adecuadamente. 4. El tratamiento de estas peticiones será bastante similar al de la primera propuesta: a) Si la petición fuera de lectura: 1) Si no tiene que ver con datos modificados o nuevos, se terminará la intercepción. 2) Si fuera sobre datos modificados, deberá mapearse 9 la petición en donde se encuentren realmente los datos. Concretamente, al soporte DE y, posiblemente, a otro bloque. b) Si la petición fuese de escritura: 1) Si fuera la primera vez que se escribe sobre esos bloques, se usarían bloques libres de DE para almacenar la información. Una vez localizados esos bloques, se utilizaría esa información para modificar la petición. 2) Si los bloques que se quisieran modificar ya lo hubieran sido previamente, se localizarían los bloques correspondientes en DE que contuvieran esa información. Igualmente, procedería a modificarse la petición. 5. Una vez que se termina la intercepción, se devuelve la petición convenientemente modificada y se deja al sistema E/S que la procese del todo. Para poder interceptar las peticiones de E/S es necesario modificar el código encargado de su recepción para que, tras unos mínimos chequeos rutinarios, y antes de enviarlo a la cola de peticiones del dispositivo correspondiente, se proceda a invocar la función encargada de retocar los valores de la petición si fuera necesario. Por ejemplo, ante una escritura, una vez modificada la petición, el sistema de E/S la enviaría a DE en vez de dejar que siguiera su curso hasta DL sobrescribiendo los datos que se quisieran proteger. De forma similar a la propuesta de modificación del sistema de memoria, en este caso hay que modificar el código, aunque sólo ligeramente, de la capa de E/S de bloques. Por tanto, algunos de los inconvenientes del caso anterior se repiten: las interfaces entre distintas versiones pueden variar, lo que obliga a un mantenimiento continuado y, además, al ser un sistema crítico, no se puede distribuir como un simple módulo. Es más, tener que tratar las opciones de montaje para saber qué soporte se usará como DE, obliga a modificar levemente el código de Ext2. Si se quiere dar soporte a otros 9 A pesar de no ser su significado real aunque esté relacionado, el verbo mapear se utilizará en este proyecto para describir la operación de consultar en una determinada estructura la posición que debe ocupar cierto dato. 24

37 2.2 Propuestas sistemas de ficheros, deberán estudiarse sus implementaciones para realizar la misma función. Al contrario que las otras soluciones, aquí el límite no es el número de bloques libres en DL sino el tamaño de DE. Como DE podría usarse una partición, un disco entero o cualquier dispositivo de bloques similar. El contenido previo de DE se perdería al realizarse las escrituras Dispositivo virtual Esta última propuesta, que se describirá a continuación y que tiene mucho en común con la inmediatamente anterior, será la que finalmente se acepte como solución. Básicamente consiste en la creación de un nuevo tipo de dispositivo de bloques virtual (DV) que será manejado por una aplicación de usuario (ver figura 2.8). Figura 2.8: Modificación propuesta: dispositivo virtual. Este nuevo dispositivo se colocará encima de DL y DE. Cualquier petición que le llegue será tratada y enviada al dispositivo correspondiente, de manera prácticamente similar a como se hacía al interceptar las peticiones de E/S. Los beneficios con respecto a la solución anterior residen en que no es necesario tocar ningún sistema del núcleo, relajando bastante las restricciones que había referentes a que futuros cambios en los sistemas modificados (VMM y BIO) afectasen a la solución y permitiendo la distribución de la solución como módulo. Para que esta propuesta funcione es necesario que, de cara al sistema, el dispositivo sea como una capa transparente sobre DL. Toda petición que le llegue será tratada y redirigida 25

38 PLANTEAMIENTO DE SOLUCIONES a donde convenga, es decir, a DL en el caso de lecturas y a DE en el caso de escrituras y también en el de lecturas sobre datos modificados de DL. Además, esta propuesta apenas está ligada a los sistemas de ficheros que usen los soportes, aunque sí deben cumplir ciertos requisitos mínimos: El sistema de ficheros debe dividir todo el soporte en bloques del mismo tamaño. Todos los accesos a los bloques deben estar alineados tanto en tamaño como en posición. La única excepción será un bloque inicial, de tamaño fijo, que describa el tamaño real del bloque de esa partición. Al igual que en el resto de propuestas, las peticiones de lectura de datos no modificados a DV serán propagadas, sin modificaciones, a DL, cambiando simplemente el dispositivo receptor de la petición y encolando de nuevo la misma en el sistema de E/S. Si las peticiones dirigidas a DV fueran escrituras o accesos de lectura a escrituras realizadas anteriormente en DE, no deberá modificarse sólo el dispositivo receptor realmente de la petición (DE) sino que además, deberá mapearse el bloque dado originalmente para DV con su correspondiente en DE. Esta propuesta creará un dispositivo virtual por cada pareja de soportes, uno que se mantendrá intacto (DL) y otro que almacenará las escrituras (DE). Mediante una aplicación de control será posible crear estos dispositivos virtuales, destruirlos, modificarlos e incluso averiguar su estado. Un objetivo adicional planteado para esta propuesta es la posibilidad de sincronizar el contenido de DE con DL. Es decir, que los cambios que se han realizado y que se perderían al retornar al estado primigenio del soporte, se escriban en DL. Este nuevo aspecto sería provechoso para el usuario ante cambios o modificaciones del SF que han sido correctas y que se quieran mantener. Finalmente, resaltar que esta propuesta es claramente más limpia que cualquiera de las anteriores, tanto por no modificar ningún sistema del núcleo como por ser fácilmente controlable por parte del usuario. Además, como más tarde se verá, esta propuesta permite usar como almacenamiento de escrituras soportes tan dispares como discos de memoria RAM y ficheros emulando dispositivos de bloques mediante loop device Permite emular un dispositivo usando un fichero. Por ejemplo, se puede emular un dispositivo de bloques como puede ser un disco de 10 GiB usando un fichero de 10 GiB. 26

39 Capítulo 3 CONCEPTOS PRELIMINARES 3.1. Introducción Este capítulo explicará algunos de los conceptos básicos de sistemas operativos que han sido necesarios para el desarrollo del proyecto, aunque se centrará la explicación en Linux por ser el sistema operativo destino elegido. Se mostrarán los prototipos internos de Linux de aquellas funciones que implementen la funcionalidad explicada y se detallará cómo se usan y cuándo conviene utilizar una función u otra Linux Linux es un sistema operativo de estilo UNIX 1 y es muy conocido por ser uno de los proyectos abanderados de los movimientos Open Source 2 y Free Software 3. Su nombre procede de su creador y principal desarrollador: Linus Torvalds. Cuando se habla de GNU/Linux se hace referencia al núcleo Linux junto con las utilidades del sistema y bibliotecas desarrolladas para el sistema operativo GNU. MINIX es otro sistema operativo de estilo UNIX, escrito por Andrew S. Tanenbaum en 1987, que se usaba principalmente con fines académicos. Sus fuentes estaban disponibles, permitiendo a cualquier estudiante de sistemas operativos disponer de un sistema funcional y que pudiese modificar para su estudio. Su principal problema es que fue diseñado para sistemas de 16 bits y no se adaptaba muy bien a la emergente popularidad de la plataforma Intel 386 de 32 bits. Linus comenzó a crear Linux como un reemplazo no comercial de MINIX. Además, decidió usar el modelo de núcleo monolítico, en vez del modelo micronúcleo de MINIX. Un micronúcleo es un núcleo con un conjunto de llamadas al sistema mínimo: comunicación entre procesos, gestión a bajo nivel del espacio de memoria, gestión de hilos, 1 UNIX fue un sistema operativo diseñado en 1969 en los Laboratorios Bell por Ken Thompson, Dennis Ritchie y Douglas McIlroy. 2 Metodología de desarrollo que ofrece acceso al código fuente de un producto. 3 Se denomina así al software que puede ser usado, estudiado y modificado sin restricción alguna y que, además, puede ser copiado o redistribuido ya sea modificado o no sin ningún tipo de restricción. 27

40 CONCEPTOS PRELIMINARES etc. El resto de llamadas clásicas de un núcleo se implementan por medio de servidores en espacio del usuario y que se apoyan en la funcionalidad proveída por el micronúcleo para poder desarrollar sus labores. Un núcleo monolítico agrupa todo el código que atiende las llamadas al sistema dentro del espacio del núcleo y con privilegios de supervisor. El principal beneficio del micronúcleo es un núcleo más pequeño, simple, fácil de depurar y de mantener. Además, la caí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 núcleo, que sí podría ocurrir con uno monolítico. Por contra, los núcleos monolíticos son más rápidos, puesto que no tienen la sobrecarga adicional del intercambio de mensajes entre los distintos servidores ni con el micronúcleo a la hora de atender una petición. Linux permite la carga y descarga de funcionalidades adicionales mediante módulos. Los módulos son fragmentos de código que aportan nueva funcionalidad al núcleo y cuyo cometido suele ser el soporte de hardware adicional o el acceso a nuevos tipos de sistemas de ficheros. Al contrario que Microsoft Windows, la interfaz gráfica no es parte del núcleo. Es uno de los sistemas más portados a otras arquitecturas y se encuentra en el 75 % 4 de los sistemas que conforman Top Está escrito en su mayor parte en C 6 con algunas partes en ensamblador y C++ 7 y engloba casi cinco millones de líneas de código. Se encuentra licenciado bajo GPL 2. La versión utilizada para el desarrollo del proyecto ha sido la , que vio la luz en septiembre del Una vez concluido el proyecto y comprobado que funcionaba correctamente, se decidió actualizar el mismo para dar soporte a la última versión disponible: , publicada en enero del Manejo de la memoria La memoria, como recurso básico 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) para solicitar memoria; las correspondientes para liberarla son kfree, vfree y free page. La función kmalloc funciona de forma parecida a la función malloc de ANSI C: se indica la cantidad de memoria requerida como primer parámetro. La diferencia se halla en el segundo parámetro, que identifica el tipo de memoria que se solicita y que puede ser de varios tipos. He aquí los principales: GFP ATOMIC: se usa para solicitar memoria desde una rutina de tratamiento de interrupción. No puede bloquearse. 4 Estudio correspondiente a junio del 2008: 5 Top500 lista los 500 sistemas de computación más potentes conocidos: org/ 6 C es un lenguaje de programación de propósito general, estructurado en bloques, procedimental e imperativo desarrollado en 1972 por Dennis Ritchie en los Laboratorios Bell. 7 C++ es un lenguaje de programación derivado de C al que añade el paradigma de programación orientada a objetos. 28

41 3.3 Manejo de la memoria GFP KERNEL: memoria normal del núcleo. Puede bloquearse. GFP NOIO: al solicitarse la memoria, no puede producirse una operación de E/S para poder satisfacer la petición. 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> void kmalloc ( s i z e t s i z e, g f p t f l a g s ) ; void k f r e e ( c o n s t v oid objp ) ; void vmalloc ( u n s i g n e d long s i z e ) ; void v f r e e ( void a ddr ) ; 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 ) ; void f r e e p a g e ( s t r u c t page page ) ; size: cantidad de memoria que se solicitará. flags: tipo de memoria solicitada. La coletilla de si la llamada puede bloquearse o no es importante. Para demostrarlo se propone el siguiente ejemplo: 1. Una función del núcleo entra en una región crítica protegida por un spin lock Invoca la función kmalloc con un tipo de memoria que puede bloquear la petición, por ejemplo GFP KERNEL. 3. El proceso se bloquea en esa función, cediendo voluntariamente el uso del procesador. 4. El planificador elige otro proceso para que entre a ejecutar. 5. El proceso, a través de una llamada al sistema, llega a ejecutar código del núcleo. 6. Al cabo de varias funciones, llega al mismo spin lock y se queda esperando que se le permita el paso a la región crítica. 8 Un spin lock es un mecanismo de sincronización donde un proceso simplemente espera en un bucle repetidamente hasta que se cumple una condición. Se explicará con más detalle en el punto

42 CONCEPTOS PRELIMINARES 7. En un monoprocesador con Linux apropiativo, el sistema seguiría ejecutando y el proceso, bloqueado a la espera de memoria libre, seguiría ahí hasta que se liberase memoria suficiente y así finalizar la región crítica. En cambio, en un multiprocesador, se perdería un procesador, pues este intentaría entrar constantemente en la región crítica. Hasta que no se satisficiese la petición de memoria, no se podría cerrar la región crítica y, por tanto, liberar el proceso que está encadenado a la comprobación del spin lock. Una vez este proceso salga de la región crítica, volvería a quedar disponible ese procesador para el resto de procesos. Por tanto, es importante no invocar funciones que puedan bloquearse dentro de regiones críticas, para no dar lugar a un bloqueo, aunque sea de manera temporal. Se ahondará más en las herramientas que ofrece el núcleo para tratar con los clásicos problemas de sincronización y acceso concurrente a estructuras en el punto 3.6. El tipo GFP NOIO suele ser utilizado por los controladores de los dispositivos de bloques para evitar llamadas eternamente recursivas, ya que el proceso, al solicitar memoria de este tipo, impone la condición de que no se produzcan operaciones de E/S para atender la petición. La motivación para usar este tipo de memoria es la siguiente: 1. Llega una petición de lectura al dispositivo A. 2. El controlador del dispositivo solicita memoria mediante kmalloc para sus gestiones internas y así poder tratar la solicitud. 3. No hay memoria disponible, por lo que el sistema de memoria virtual decide expulsar de memoria unos bloques modificados del mismo dispositivo A. 4. Por tanto, esos bloques se envían al controlador del dispositivo para que los escriba en el soporte. 5. Para escribirlos, necesita memoria que solicita y vuelta a empezar. El resultado evidente es que no habrá fin para la solicitud de memoria, a menos que se consiga liberar de otra forma: desechando bloques no modificados en memoria, datos en caché, etc. Para evitar esta situación, al solicitar memoria, se añade la siguiente restricción: la función encargada de localizar memoria libre no puede emplear operaciones de E/S. El uso de kmalloc sólo se recomienda para peticiones inferiores a 128 KiB. Para tamaños mayores, es preferible el uso de vmalloc o gestionar, de manera personalizada, las distintas páginas de memoria obtenidas mediante alloc page. El funcionamiento de vmalloc es igual al de kmalloc: la diferencia radica en cómo se gestiona internamente la solicitud de memoria. Cuando la petición se hace mediante kmalloc, la memoria obtenida se encuentra en páginas de memoria consecutivas físicamente. Por el contrario, al pedirla a través de vmalloc, la memoria se encontrará en páginas de memoria no contiguas físicamente, aunque sí desde el punto de vista del espacio de memoria virtual. 30

43 3.4 Informar al usuario La memoria solicitada con kmalloc se libera con kfree mientras que vfree se usa para la solicitada con vmalloc. A veces es preferible trabajar directamente con las páginas de memoria, páginas que se pueden solicitar mediante la función alloc page. Esta función recibe el ya clásico parámetro que indica el tipo de memoria solicitada y que ya se explicó anteriormente. El resultado de la función es una página de memoria, normalmente de 4 KiB. Una vez que se termine de utilizar la página, se devuelve al núcleo mediante la función free page Informar al usuario Para poder mostrar texto al usuario se utiliza la función printk. Su funcionamiento es calcado al de la función printf de ANSI 9 C, aunque tiene una diferencia importante: hay que indicar el nivel de alerta del mensaje. Dependiendo de este nivel de alerta, el mensaje se almacenará en el registro de eventos o, adicionalmente, si fuera muy importante, se mostrará al usuario por las consolas activas. # 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> Listado 3.2: Niveles de alerta para printk. i n t p r i n t k ( c o n s t c h a r fmt,... ) ; A continuación el significado de cada uno de los niveles: KERN EMERG: mensajes de emergencia, normalmente aquellos que preceden a una caída del sistema. KERN ALERT: situaciones que requieren una acción inmediata. KERN CRIT: condiciones críticas, a menudo relacionadas con fallos hardware o software. KERN ERR: condiciones de error. KERN WARNING: situaciones problemáticas, pero que no deberían crear problemas graves al sistema. 9 American National Standards Institute o Instituto de Estándares Nacionales Americanos. 31

44 CONCEPTOS PRELIMINARES KERN NOTICE: situaciones normales, pero que merece la pena notificar como avisos relacionados con la seguridad del sistema. KERN INFO: mensajes informativos: utilizado por muchos controladores durante su inicialización para informar del hardware que han encontrado. KERN DEBUG: mensajes de depuración Gestión de errores La gestión de errores en el núcleo 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 código difícil de leer y mantener, pues altera el flujo de ejecución y obliga al programador a saltar de función en función, en vez de encapsular la lógica en funciones e invocarlas según se requiera. En cambio, en la gestión de errores su uso evita que se replique el código dedicado a deshacer y/o liberar recursos una vez falla la petición de acceso a uno de ellos. Como muestra, compárese 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 ( void ) { 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

45 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 ( void ) { 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 ) g oto 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 ) g oto 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 ) g oto 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 más intuitivo el listado 3.4 que el 3.3. Además, si hay que corregir alguna variable o nombre de función, es más fácil, y menos propenso a errores, hacerlo en un único bloque, el último, que ir revisando todos los posibles bloques Concurrencia y condiciones de carrera Introducción En la rama 2.4 del núcleo Linux, cuando a un proceso que estaba ejecutando código del núcleo se le acababa su porción de tiempo asignado, lo normal era esperar a que invocase una llamada bloqueante o decidiese retornar al espacio de usuario. En ese momento, el núcleo podía realizar un cambio de contexto y poner a ejecutar a otro proceso. A partir de la rama 2.6 de Linux, el núcleo es apropiativo o preemptive, es decir, en cualquier momento, un proceso ejecutando código del núcleo puede ser expulsado y sustituido por otro proceso cualquiera. Este cambio plantea una serie de problemas, sobre todo con el acceso a variables globales o compartidas: las condiciones de carrera. Por ejemplo: 1. Un proceso A que está ejecutando código del núcleo decide incrementar un contador 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

46 CONCEPTOS PRELIMINARES 5. El proceso B lleva a cabo la tarea y cede el procesador. 6. El proceso A reanuda su ejecución y, al actualizar el contador, escribe datos que no son correctos, pues no ha tenido en cuenta el decremento del proceso B. Para eliminar estos problemas y otros muy relacionados, como son el acceso concurrente a la misma estructura al ejecutar el mismo código en distintos procesadores de manera simultánea, el núcleo provee de herramientas de sincronización entre procesos. Estas herramientas ayudan a crear regiones críticas, donde se garantiza la atomicidad de las operaciones contenidas dentro de ellas. Las herramientas más utilizadas son los semáforos y los spin lock y su funcionamiento, al igual que con muchas de las funciones ya comentadas, es muy similar a sus contrapartidas disponibles en el espacio de usuario Semáforos Un semáforo es un contador combinado con dos funciones: down y up. Cuando se quiere entrar en una región crítica, el proceso invoca la función down. Si el contador es mayor que cero, el proceso continua su ejecución. Una vez dentro, realiza sus labores y termina invocando la función up, la cual pone fin a la región crítica incrementando el valor del contador. Si el valor del contador es cero cuando un proceso ejecuta down, entonces, este es suspendido a la espera de que otro proceso, dentro de la región crítica, libere el semáforo. El valor del contador con el que se crea el semáforo sirve de indicativo de cuántos procesos pueden entrar en la misma región crítica. Un caso particular de los semáforos es aquel cuyo valor inicial es uno. En este tipo de semáforos, también conocidos como mutex, sólo se permite un proceso dentro de la región crítica. Los semáforos son creados usando la función sema init, donde el primer parámetro es el semáforo que se va a crear y el segundo el valor inicial de salida del mismo. # i n c l u d e <asm / semaphore. h> Listado 3.5: Operar con semáforos. void s e m a i n i t ( s t r u c t semaphore sem, i n t v a l ) ; void down ( s t r u c t semaphore sem ) ; void up ( s t r u c t semaphore sem ) ; Existe un caso particular de semáforos conocido como semáforos lectura/escritura. En estos semáforos, no se discrimina según el valor del contador sino dependiendo del tipo de operación que se quiera llevar a cabo: si el código de la región crítica va a consistir en lecturas concurrentes sobre estructuras o variables compartidas, entonces no hay problema, pueden entrar cuantos procesos quieran. En cambio, si se trata de una escritura, sólo puede pasar uno, puesto que sólo tiene sentido que un proceso realice modificaciones. 34

47 3.6 Concurrencia y condiciones de carrera Este tipo de semáforos puede optimizar bastante el rendimiento si hay muchas más peticiones de lectura que escritura, ya que todas las lecturas pueden acceder concurrentemente. Como pueden coincidir muchas lecturas a la vez y para evitar inanición por parte de las peticiones de escritura, se suele dar mayor prioridad a estas últimas. En cambio, el problema de la inanición podría pasarse a las lecturas si hubiera demasiadas escrituras o estas tardasen mucho en salir de la región crítica. Por tanto, este tipo de semáforos no es muy utilizado, a no ser que apenas haya accesos de escritura. Finalmente, la función de inicialización de este tipo de semáforos es init rwsem y recibe como único parámetro una estructura que representa al semáforo a crear. # i n c l u d e <l i n u x / rwsem. h> Listado 3.6: Operar con semáforos lectura/escritura. void i n i t r w s e m ( s t r u c t rw semaphore sem ) ; void d o w n r e a d ( s t r u c t rw semaphore sem ) ; void d o w n w r i t e ( s t r u c t rw semaphore sem ) ; void u p r e a d ( s t r u c t rw semaphore sem ) ; void u p w r i t e ( s t r u c t rw semaphore sem ) ; Spin lock A diferencia de los semáforos que suspenden al proceso mientras espera que le permitan pasar dentro de la región 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 donde la 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 comprobación del valor de una variable. Esta variable es la encargada de permitir o denegar el paso a la región crítica en función del estado que indique. Obviamente, el proceso de consulta de la variable, y modificación, si se permite el paso, es atómico para evitar que varios procesos entren a la vez dentro de la región crítica. Para crear un spin lock se utiliza la función spin lock init que recibe como único parámetro una estructura que representará al spin lock. Para intentar entrar en la región crítica se usa la función spin lock. Una vez se quiera terminar y liberar el spin lock se usará la función spin unlock. Es muy importante recalcar que un proceso que ha obtenido un spin lock, es decir, está dentro de la región crítica, no puede hacer llamadas bloqueantes, puesto que en ese caso cedería el uso del procesador. Otro proceso podría intentar entrar en la misma región crítica y bloquearse activamente esperando que se libere el paso protegido por el spin lock. Esto podría no suceder nunca, si el único que puede hacerlo esta suspendido y el procesador está empleándose en acceder al spin lock. 35

48 CONCEPTOS PRELIMINARES # i n c l u d e <l i n u x / s p i n l o c k. h> Listado 3.7: Operar con spinlock. void 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 ) ; void s p i n l o c k ( s p i n l o c k t l o c k ) ; void 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 semáforos, existe una variante de lectura/escritura para spin lock. Estos cierres permiten un número cualquiera de procesos lectores dentro del spin lock, pero sólo un escritor en solitario puede acceder a la sección crítica. Su utilización es prácticamente igual a la de los spin lock clásicos. # i n c l u d e <l i n u x / s p i n l o c k. h> Listado 3.8: Operar con spinlock lectura/escritura. void r w l o c k i n i t ( r w l o c k t l o c k ) ; void r e a d l o c k ( r w l o c k t l o c k ) ; void r e a d u n l o c k ( r w l o c k t l o c k ) ; void w r i t e l o c k ( r w l o c k t l o c k ) ; void w r i t e u n l o c k ( r w l o c k t l o c k ) ; 36

49 Capítulo 4 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN 4.1. Introducción En este capítulo se describirá, en primer lugar, la construcción del controlador paso a paso, explicando los sistemas implicados, justificando las decisiones tomadas e ilustrando, en la medida de lo posible, con fragmentos del código desarrollado. Este controlador tendrá una funcionalidad mínima: registrarse en el sistema, inicializar y detener el dispositivo, permitir que se encolen las peticiones de E/S, etc. También se explicarán las estructuras creadas para el controlador, a fin de facilitar el seguimiento mediante los ficheros fuente del mismo. Es necesario recalcar que, puesto que un desarrollo dentro del núcleo no suele ser muy corriente, se ha preferido dar un toque más pedagógico a la documentación, incorporando fragmentos de código del proyecto, ya sean funciones o estructuras. Aunque pueda parecer que entorpece la lectura el mezclar código con texto normal, ayuda a tener una mayor compresión del desarrollo, si después de introducir un tema, éste es acompañado de código, sobre todo si es código real de la solución. En este siguiente apartado es donde se mostrará cómo trata el controlador las peticiones que le llegan y cómo actúa sobre ellas: a veces las fragmentará para enviarlas a distintos puntos del mismo dispositivo, o puede que a los dos dispositivos a la vez; otras veces las encaminará hacia uno de los dispositivos sin modificar nada más de la petición. Además, se explicará con detalle la estructura de una petición de E/S y cómo es atendida por el controlador del dispositivo destino. 37

50 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN 4.2. Creación del dispositivo virtual Estructura de módulo Normalmente, al crear nuevos dispositivos para Linux, se les suele dar carácter de módulo. Los módulos son ficheros de código objeto que permiten añadir nuevas funcionalidades o características al núcleo. Ejemplos de software que se distribuyen como módulos son los sistemas de ficheros y controladores para dispositivos hardware. Se obtienen al compilar los ficheros fuentes en lenguaje C y suelen hacer uso de los distintos mecanismos y sistemas del núcleo. El usuario, al compilar estos ficheros, puede elegir entre generar un módulo o integrarlos en la imagen del núcleo. Para crear un módulo en Linux basta con definir dos funciones: una de inicialización y otra de terminación. La función de inicialización tendrá el prefijo init mientras que la de terminación usará exit. El prefijo init le indica a Linux que esa función puede ser eliminada de memoria una vez ejecutada, para así poder disponer de la memoria que ocupaba. En cambio, el prefijo exit marca las funciones que podrán ser desechadas al compilar los fuentes dentro de la imagen de Linux en vez de como módulo. Si los fuentes van a ser compilados como parte de la imagen del núcleo, no tiene sentido añadir todas aquellas funciones encargadas de tratar la eliminación o descarga del módulo de memoria. Además de los prefijos mostrados, se dispone de una serie de macros 1 que el creador del módulo puede usar para aportar más información sobre el módulo. Algunas de ellas son obligatorias como module init o module exit. Las macros disponibles, algunas completamente en mayúsculas y otras en minúsculas, son las siguientes: MODULE ALIAS BLOCKDEV MAJOR (major): el módulo da soporte a los dispositivos que usen este major 2. MODULE AUTHOR (autor): datos del autor del módulo. MODULE DESCRIPTION (descripción): breve descripción del módulo. module exit (función de eliminación): su único parámetro es el nombre de la función que se invocará cuando se quiera eliminar el módulo. module init (función de entrada): su único parámetro es el nombre de la función que hace de punto de entrada al módulo. MODULE LICENSE (licencia): el tipo de licencia de uso. module param (nombre, tipo): para poder pasar distintas opciones al módulo durante la inicialización se usa esta macro que recibe dos parámetros. El primer parámetro es el nombre de la variable que recibirá el valor y el segundo es el tipo de esa variable. 1 Una macro o macroinstrucción es una serie de instrucciones que se almacenan para que se puedan ejecutar de forma secuencial mediante una sola llamada u orden de ejecución. 2 La explicación sobre el valor major se dará en el siguiente punto. 38

51 4.2 Creación del dispositivo virtual MODULE PARM DESC (nombre, descripción): permite describir el significado de los parámetros de la macro anterior. Recibe dos parámetros: el nombre del parámetro y su descripción. MODULE SUPPORTED DEVICE (nombre): nombre del dispositivo al que dará soporte este módulo. Por ahora no se utiliza. MODULE VERSION (versión): versión del módulo. Usando las macros descritas, el esqueleto del módulo quedaría tal y como se ve en el listado 4.1. La licencia escogida es la GPL v2 3 y además el módulo puede recibir un parámetro opcional que indique cuántos dispositivos virtuales se van a crear. Por defecto, crea sólo uno. # 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 ; Listado 4.1: Esqueleto de código del módulo / 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 ( void ) { / 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 be between 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 void e x i t r b d e x i t ( void ) { 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 ) ;

52 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN MODULE AUTHOR ( R a f a e l Antonio P o r r a s Samaniego <r a f d i s t r o b i t. net > ) ; MODULE DESCRIPTION ( C r e a t e s a r o l l b a c k device, 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. ) ; module param ( max rbd, i n t, 0) ; MODULE PARM DESC ( max rbd, Maximum number of 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 código: todas aquellas funciones que no deban ser visibles más allá del fichero de código actual deberán llevar el prefijo static. La mayoría de los datos guardados mediante las macros pueden obtenerse usando la herramienta modinfo. En el listado 4.2 se puede ver el resultado de ejecutar modinfo sobre el módulo definido anteriormente. Listado 4.2: Ejemplo de modinfo f i l e n a m e : rbd. ko v e r s i o n : 0. 1 a l i a s : block 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 device, 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 Antonio P o r r a s Samaniego <r a f d i s t r o b i t. net > l i c e n s e : GPL v2 s r c v e r s i o n : 93D79F8BB4CAAE0CBADC922 depends : vermagic : preempt mod unload parm : max rbd : Maximum number of 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 último apunte, indicar que lo deseable es situar, en la medida de lo posible, la mayor cantidad de código en espacio del usuario, en vez de en el módulo: por simplicidad a 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 aplicación 4, mientras que en el núcleo puede degenerar en un kernel panic 5 que derrumbe todo el sistema Registro del dispositivo En Linux, todos los dispositivos que se encuentran en el directorio /dev están identificados por: Un major number que identifica al tipo de dispositivo. 4 En estos casos, la aplicación suele terminar abruptamente con el siguiente mensaje: Segmentation fault. 5 Es un mensaje mostrado por el SO una vez detectado un error interno de sistema del cual no puede recuperarse. 40

53 4.2 Creación del dispositivo virtual 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 carácter en carácter y no suelen permitir el acceso aleatorio a los datos (terminales, módem, secuenciador de sonido, etc). Los dispositivos de bloques, en cambio, permiten acceder, ya sea secuencialmente o de manera aleatoria, a los datos mediante bloques (discos duros, DVD, etc). En el listado 4.3 se puede observar cómo el secuenciador de sonido es un dispositivo de caracteres (letra c en la primera columna) con un major 14 y un minor 1. También aparece un disco duro SATA 6 como dispositivo de bloques (letra b ) y cuyo major es 8 y su minor es 0. Listado 4.3: Extracto del directorio /dev brw r 1 r o o t d i s k 8, 0 a b r 29 16:36 / dev / sda crw 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 asignado por convenio, necesitará de uno propio. Este valor se asocia al tipo de dispositivo en el momento de registrarlo en el sistema mediante la función register blkdev (ver listado 4.4). # i n c l u d e <l i n u x / f s. h> Listado 4.4: Función de registro del dispositivo de bloques. 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ía uno libre. name: nombre del tipo de dispositivo con el que aparecerá listado en /proc/devices. Al revisar el documento Documentation/devices.txt de Linux, que lista los major asignados a cada dispositivo en Linux, se observó que existía un rango de major reservado para uso local. En concreto, el rango va de 240 a 254, así que se tomó el valor 240 como major del dispositivo que se está desarrollando. Por tanto, en el listado 4.5, la constante MAJOR RBD vale 240 y se procede a registrar el dispositivo rbd en la función rbd init; la función rbd exit se encargará de deshacer el registro y de liberar el major. 6 Serial ATA es una interfaz de transferencia de datos entre la placa base y algunos dispositivos de almacenamiento como discos duros, disquetes, etc. Su principal diferencia con PATA o Parallel ATA es la reducción del número de hilos empleados en la comunicación pasando de usar 40 a solo 7. 41

54 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN 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 ( void ) {... / 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 void e x i t r b d e x i t ( void ) {... / 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 ) ;... } Disco virtual El dispositivo virtual que se va a crear será un disco duro virtual situado encima de dos soportes: uno que sólo permitirá lecturas y otro que almacenará las escrituras y las lecturas sobre estas. Para crear dispositivos de bloques, Linux provee de un API específica para simplificar su generación y manejo. Estos dispositivos son descritos mediante una estructura gendisk cuyos campos (solo se muestran los más importantes en el listado 4.6) deben ser inicializados en primer lugar por el núcleo. La función alloc disk se encarga de esta inicialización y retorna la estructura lista para usar. Después será el turno, para el código que solicitó la estructura, de terminar de rellenar los campos restantes antes de poner el disco a disposición del sistema mediante la función add disk. Cuando se quiera eliminar el dispositivo, deberá invocarse la función del gendisk para retirarlo del sistema. Una vez hecho, la estructura será devuelta al núcleo mediante la función put disk. 42

55 4.2 Creación del dispositivo virtual # i n c l u d e <l i n u x / genhd. h> Listado 4.6: Estructura gendisk. 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 disk 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 ; void 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 ) ; void a d d d i s k ( s t r u c t g e n d i s k gd ) ; void d e l g e n d i s k ( s t r u c t g e n d i s k gd ) ; void p u t d i s k ( s t r u c t g e n d i s k d i s k ) ; void s e t c a p a c i t y ( s t r u c t g e n d i s k disk, s e c t o r t s i z e ) { disk >c a p a c i t y = s i z e ; } major: major del dispositivo tal y como se explicó en el punto first minor: minor que diferencia esta instancia del dispositivo. minors: el número de particiones que permite el dispositivo. disk name: nombre del dispositivo. fops: apunta al conjunto de funciones encargadas de tratar ciertas operaciones sobre el dispositivo. queue: cola de peticiones para este dispositivo; de ella se hablará más adelante en el punto private data: guarda información propia del dispositivo. capacity: almacena la capacidad del disco medida en sectores de 512 bytes. Este valor debe ser fijado mediante la función set capacity. 43

56 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN flags: indica distintas peculiaridades del disco, como por ejemplo si permite o no particiones. Aunque existen discos con un tamaño de sector distinto de 512 bytes, este suele ser el más común. Por ello, Linux visualiza cada dispositivo como una lista de sectores de 512 bytes, dejando en manos del controlador del hardware la tarea de traducir las posiciones entre ese tamaño y el propio del dispositivo. Es ya clásico en Linux habilitar soporte en caliente para nuevos objetos, como dispositivos o sistemas de ficheros, definiendo una interfaz de funciones. Todo objeto que quiera ser cargado en memoria en tiempo de ejecución necesitará ser enganchado al núcleo por medio de punteros a funciones. En nuestro caso, el campo fops apuntará a las funciones encargadas de tratar las distintas operaciones (ver listado 4.7) sobre el dispositivo, aunque sólo se explicarán 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, unsigned, u n s i g n e d l ong ) ; long ( u n l o c k e d i o c t l ) ( s t r u c t f i l e, unsigned, u n s i g n e d long ) ; long ( c o m p a t i o c t l ) ( s t r u c t f i l e, unsigned, 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 l ong ) ; 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 geometry ) ; s t r u c t module owner ; } ; El listado 4.8 muestra la creación y la destrucción del dispositivo. Como en este dispositivo no se permitirán particiones, se inicializa el campo minors con el valor 1 y se habilita el flag GENHD FL SUPPRESS PARTITION INFO en el campo flags. El nombre del dispositivo constará del prefijo rbd seguido de un número que identifica la instancia. El campo private data apunta a una estructura particular de cada instancia que contiene información que le afecta solamente a ella. Esta estructura será explicada más detalladamente en el punto Finalmente, la capacidad no se indica, puesto que se desconoce; hasta que no se conozca cuál es el tamaño del soporte que se protegerá, será imposible dar el tamaño del disco, pues deben coincidir completamente. 44

57 4.2 Creación del dispositivo virtual Listado 4.8: Creación y destrucción 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 s d 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 = ( void ) 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 void rbd remove ( void ) {... 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 ) ;... } / Operaciones 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

58 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN Método open Se encarga de tramitar la apertura del dispositivo para poder acceder a él. En nuestro caso, al ser un dispositivo virtual, su única labor consiste en incrementar un contador de aperturas. De esta forma, se impide eliminar el dispositivo mientras no se hayan cerrado todas las peticiones de apertura. Listado 4.9: Método 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 ; Método release Se encarga del cierre del dispositivo. En nuestro caso, decrementa el contador de aperturas. Listado 4.10: Método 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 ; Método getgeo Devuelve la geometría CHS 7 del disco. Esta información sólo tiene sentido cuando se ha inicializado el dispositivo y, por tanto, se conoce el número de sectores del dispositivo de lecturas. 7 Cilindro-cabeza-sector, del inglés Cylinder-Head-Sector, es un método para acceder a un determinado sector del disco mediante estas tres coordenadas. 46

59 4.2 Creación del dispositivo virtual 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: Método 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 geometry 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 ; } / Geometria 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 ; Método ioctl Su función es tratar las peticiones ioctl, que se explicarán detenidamente en el punto Estas peticiones ioctl sirven para interactuar con el dispositivo y así poder controlarlo mediante comandos, por ejemplo, para crear o eliminar dispositivos virtuales Cola de peticiones Toda petición 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. Por ejemplo, en el caso de una petición de escritura de una aplicación, se encola la petición y la aplicación puede seguir trabajando en vez de esperar bloqueada. Además, al encolar la peticiones se puede optimizar la forma de tratarlas. Esta optimización se consigue si, en vez de servir y atender las peticiones según 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 los cabezales sea mínimo. Por ejemplo, en vez de atender una petición en el borde del disco, luego una interior y finalmente una a medio camino, sería mucho más rentable en tiempo acceder de fuera hacia dentro, es decir, empezando en la más exterior, seguir con la del medio y terminar con la petición interior. 47

60 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN El principal beneficio es la reducción de los tiempos de acceso para satisfacer las distintas peticiones y, como beneficio adicional, reducir el desgate mecánico. Los encargados de reordenar y/o fusionar las peticiones son conocidos como planificadores de E/S y Linux ofrece varios de ellos: Anticipatory: este algoritmo intenta maximizar el rendimiento anticipándose a las lecturas síncronas. Normalmente, los procesos leen datos de un soporte y, una vez han sido procesados, vuelven a leer del soporte. Con un planificador más conservador, este tipo de situación produciría que, ante una aparente finalización en la lectura de datos, se atendiese las peticiones de otro proceso. Si después de que empiece a atenderse el otro proceso, el primero vuelve a solicitar datos, se produciría una pequeña sobrecarga de búsqueda y acceso a disco. Habría sido más rentable terminar con las peticiones del primer proceso antes de mover las cabezas a la zona de trabajo del segundo proceso. La solución que propone este algoritmo es esperar unos pocos milisegundos después de completar las peticiones de un proceso, por si acaso enviara algunas más a la cola. Este planificador no se recomienda en sistemas RAID por hardware. Deadline: este planificador intenta garantizar que cada petición será servida antes de un tiempo límite, normalmente 500 ms para las peticiones de lectura y 5 s para las escrituras. Las lecturas tienen preferencia sobre las escrituras, puesto que ante una lectura 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 duplicidad se debe al distinto tratamiento que se da a la petición si es lectura o si es escritura. Las colas de tiempo límite se ordenan por su tiempo de expiración y las otras por el número de sector. Cuando se decide atender una petición, el planificador comprueba la cola de tiempo límite para ver si alguna petición ha expirado y, si es así, atenderla. En caso contrario, 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 petición síncrona en una cola particular de cada proceso. Después, da a cada cola un tiempo definido para que complete el mayor número de peticiones posibles. La duración de este tiempo y el número de peticiones que puede tener encoladas un proceso depende de la prioridad de E/S del mismo. Dependiendo de su prioridad, las peticiones asíncronas son encoladas todas juntas en unas pocas colas. Aunque su objetivo no es funcionar como el planificador Anticipatory, consigue el mismo resultado, puesto que, al terminar de servir las peticiones de un proceso, el planificador queda a la espera de que lleguen más del mismo mientras no se consuma del todo su porción de tiempo. 48

61 4.2 Creación del dispositivo virtual Noop: es un planificador muy simple que sólo fusiona aquellas peticiones adyacentes en el disco, sin preocuparse de reordenar la cola de peticiones. Todo dispositivo de bloques tiene una cola de peticiones donde operan estos algoritmos con el fin de optimizar las operaciones de E/S, pero hay casos en los que es inútil. Uno de esos casos es este proyecto o aquel caso en el que el dispositivo es un RAID 8, ya que no existe el dispositivo realmente, sino que las peticiones que les lleguen serán redistribuidas a otros dispositivos físicos que sí sacarán provecho de estos algoritmos. Por tanto, sólo requieren de una cola de peticiones en el sentido de que necesitan que les lleguen las peticiones, pero no serán tratadas por el núcleo para optimizar el acceso al dispositivo. El primer paso para que nuestro dispositivo disponga de una cola es crear una mediante la función blk alloc queue. Esta función recibe como parámetro el tipo de memoria 9 que se usará, normalmente memoria estándar del núcleo o GFP KERNEL; devuelve la cola creada o error si hubo fallo. Para devolver la cola al sistema se usa la función blk put queue. # i n c l u d e <l i n u x / b l k d e v. h> Listado 4.12: Gestión de colas de dispositivo. 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 ) ; void 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 ) ; void 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 asociará la función. mfn: función a asociar a la cola, que deberá ser como la función make request fn. Una vez que se dispone de la cola es necesario asociarle una función propia que se encargará de gestionar las peticiones que lleguen a la misma. La asociación de la cola con la función deseada se realiza mediante la función blk queue make request. En nuestro caso, se han desarrollado dos funciones: 8 Acrónimo de Conjunto redundante de discos baratos, del inglés Redundant Array of Inexpensive Disks, y hace referencia a un sistema de almacenamiento que usa múltiples discos duros entre los que distribuye o replica los datos. 9 Para una discusión sobre los tipos de memoria y las funciones existentes para solicitarla acuda al punto

62 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN 1. rbd make request fail: esta función retorna con error todas las peticiones que le llegan. Su propósito es simple: sirve de contención hasta que se definan los soportes a los que el dispositivo despachará las peticiones. 2. mapeo make request: esta es la función principal encargada de trasladar las peticiones que le lleguen al dispositivo virtual. Decidirá, según el tipo de petición (lectura o escritura) y los sectores accedidos, a qué dispositivo y a qué sector debe redirigir la petición. Esta función se explicará más detalladamente en el punto Finalmente, se incluye el código del proyecto (fragmento 4.13) que hace uso de lo explicado en este punto. Listado 4.13: Creación 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;... } goto 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 >cola, r b d m a k e r e q u e s t f a i l ) ; dev >cola >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 void rbd remove ( void ) {... b l k p u t q u e u e ( dev >c o l a ) ;... } Control de entrada y salida Introducción Además de las operaciones clásicas de lectura y escritura sobre un dispositivo, los dispositivos 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 él para poder indicarle multitud de cosas: qué dispositivo usará para las lecturas y cuál para 50

63 4.2 Creación del dispositivo virtual las escrituras, poner en marcha o detener el dispositivo, solicitar información del estado del mismo, etc. Este control se realiza mediante una interfaz denominada ioctl 10 y permite enviar unos comandos previamente definidos al dispositivo. Para ello, basta con enviar mediante la función ioctl el comando deseado al dispositivo que corresponda, el cual estará representado por un descriptor de fichero. Adicionalmente, se puede pasar una variable que contenga datos necesarios para completar el comando o, por el contrario, lo usará el controlador para devolver algún tipo de información al usuario. Listado 4.14: Página 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 núcleo, y más concretamente del controlador que tratará la petición ioctl, la función encargada de analizar y actuar adecuadamente ante la petición tiene que calcar la definición del prototipo que se indica en el listado Esta función retornará cero si todo ha ido correctamente, o error en caso contrario. El estándar POSIX 11 obliga a devolver el código de error -ENOTTY si el comando recibido es inapropiado. # i n c l u d e <l i n u x / f s. h> Listado 4.15: Función ioctl. 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, unsigned, u n s i g n e d long ) ; El núcleo sabe a qué función tiene que pasarle la petición, puesto que, al registrar el dispositivo, ya se le indicó, dentro de la estructura block device operations, mediante el campo ioctl. En nuestro caso la función indicada fue rollback ioctl. Sólo se explicará la parte de ioctl relativa al núcleo. La parte correspondiente al espacio del usuario será explicada brevemente en el apéndice A Comandos Para nuestro dispositivo se definieron ocho posibles comandos (ver listado 4.16) que permitiesen un control absoluto del mismo: Version: informa de la versión del controlador. El controlador devolverá a la aplicación un entero que identifica la versión. Info: aporta información sobre el estado de un dispositivo. Esa información incluye datos como qué dispositivo está usando para las lecturas y cuál para las escrituras, la 10 Acrónimo de input/output control o control de entrada y salida. 11 Acrónimo de Portable Operating System Interface (la X viene de UNIX como seña de identidad del API) que engloba a una familia de estándares de llamadas al SO que persigue generalizar las interfaces de los SO para que una misma aplicación pueda ejecutarse en distintas plataformas. 51

64 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN memoria ocupada en el núcleo por ahora, el máximo previsto, el número de bloques disponibles, etc. Toda esta información es proporcionada por el controlador por medio de una estructura creada ad hoc denominada rbd info ioctl. Create: se encarga de indicar al dispositivo qué dispositivo usará para las lecturas y cuál para las escrituras. Para tal fin usa una estructura denominada rbd create ioctl. Delete: indica al controlador que libere los dispositivos adquiridos por medio del comando Create. Run: indica al dispositivo que empiece a funcionar. Hasta que no se envíe este comando, el dispositivo estará detenido. Recibe un entero que es un porcentaje mínimo de bloques libres que debe haber. Si se traspasa ese límite, el controlador avisará al usuario de que empieza a haber pocos bloques libres. Stop: detiene el dispositivo indicado y, por tanto, las operaciones sobre él. Es el paso previo a eliminarlo mediante el comando Delete. No necesita de ningún parámetro adicional. Reset: le indica al dispositivo que ejecute el comando Stop seguido de un Run. Así se consigue reiniciar el dispositivo rápidamente. Como este comando es un alias para la operación conjunta representada por Stop y Run, acepta el parámetro de este último. Sync: realiza una sincronización de contenido entre el dispositivo de escrituras y el de lecturas, actualizando el contenido de este último con las modificaciones almacenadas en el primero. Tampoco necesita de ningún parámetro 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 números, por ejemplo empezando en uno, esto no es lo deseable. El motivo es evitar mandar un comando por error a un dispositivo que no le corresponde y que, a pesar de ello, le afecte, 52

65 4.2 Creación del dispositivo virtual puesto que no son únicos. Así que lo mejor es intentar garantizar, en la medida de lo posible, la unicidad de los distintos comandos. La solución pasa por crear los comandos ioctl mediante la concatenación de distintos campos: type: identifica al dispositivo, por tanto, cada tipo de dispositivo debería tener un número único asignado. Hay un listado de números asignados que se puede consultar en el fichero Documentation/ioctl-number.txt de Linux. number: es un cardinal que discrimina entre varios comandos del mismo tipo de dispositivo. direction: indica la dirección de la transferencia de datos, siempre desde el punto de vista de la aplicación. Hay tres posibilidades: IOC NONE: no hay transferencia de datos. IOC READ: se transfieren datos del controlador a la aplicación. IOC WRITE: se transfieren datos de la aplicación al controlador. size: informa del tamaño de los datos que se transmiten entre la aplicación y el controlador. Como siempre, en aras de facilitar el desarrollo, Linux ofrece una serie de macros que se encargan de dirimir con los distintos campos. Las macros disponibles pueden verse a continuación: # 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 ) Listado 4.17: Macros para la creación de ioctl. 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

66 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN Tratamiento Ya se han definido los comandos ioctl que aceptará el dispositivo. El siguiente paso es tratarlos dentro del controlador para que, dependiendo del comando, se obre en consecuencia. La mayoría de los comandos requieren una transferencia de datos entre el espacio de memoria del usuario y el propio del núcleo. Estas condiciones imponen el uso de una serie de funciones adicionales: access ok comprueba si el parámetro, un puntero, apunta a una posición de memoria dentro del mapa de memoria del proceso que es accesible desde el núcleo. Una vez se sabe que es accesible el puntero y se quiere leer del mismo la información apuntada, debe usarse alguna de las siguientes funciones: get user o copy from user. Las dos copian a espacio del núcleo el contenido al que apunta el puntero, pero con una pequeña diferencia: get user está especializada en tipos de datos clásicos (entero, byte, etc), mientras que copy from user se usa para estructuras o similares. Del mismo modo que hay unas funciones para leer del espacio del usuario, hay otras para escribir. Son put user y copy to user y su utilización es semejante a las de 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> bool a c c e s s o k ( type, addr, s i z e ) ; void g e t u s e r ( x, p t r ) ; void p u t u s e r ( x, p t r ) ; Como ya se comentó en la introducción, la función rollback ioctl es la encargada de gestionar las peticiones enviadas al dispositivo y ahora se explicará qué hace realmente con cada petición: Info: recaba toda la información que necesita y la vuelca en la estructura rbd info ioctl. Listado 4.19: Ioctl RBD INFO. c a s e RBD INFO : / Estado d e l d i s p o s i t i v o / / Comprobar e l d ato y r e a l i z a r e l IOCTL / i f (! a c c e s s o k ( VERIFY WRITE, ( void 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 dato a l e s p a c i o de u s u a r i o / 54

67 4.2 Creación del dispositivo virtual 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 estructura 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 acceso / i f (! c a p a b l e ( CAP SYS ADMIN ) ) r e t u r n EACCES ; / Comprobar e l dato y r e a l i z a r e l IOCTL / i f (! a c c e s s o k ( VERIFY READ, ( void u s e r ) arg, IOC SIZE ( cmd ) ) ) r e t u r n EFAULT ; 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 / / C o n t r o l de acceso / i f (! c a p a b l e ( CAP SYS ADMIN ) ) r e t u r n EACCES ; / 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 indicado por arg. 55

68 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN 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 / / C o n t r o l de a c c e s o / i f (! c a p a b l e ( CAP SYS ADMIN ) ) r e t u r n EACCES ; / 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 / / C o n t r o l de a c c e s o / i f (! c a p a b l e ( CAP SYS ADMIN ) ) r e t u r n EACCES ; / 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 detrás de otro. 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 / / C o n t r o l de a c c e s o / i f (! c a p a b l e ( CAP SYS ADMIN ) ) r e t u r n EACCES ; / 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 sincronización 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 a c c e s o / i f (! c a p a b l e ( CAP SYS ADMIN ) ) r e t u r n EACCES ; / 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

69 4.2 Creación del dispositivo virtual Version: se limita a copiar la versión en la posición apuntada por el parámetro 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 dato 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, ( void u s e r ) arg, IOC SIZE ( cmd ) ) ) r e t u r n EFAULT ; 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, ya que, de no ser así, cualquier usuario podría realizar cambios en el dispositivo. Los únicos comandos que un usuario normal debería poder invocar son los informativos (Info y Version). Esta protección se consigue comprobando, mediante la función capable, si el usuario que envía el comando tiene permisos de administrador (CAP SYS ADMIN). # 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 Listado 4.27: Comprobación de permisos Miscelánea En este apartado se explicarán ciertas partes del desarrollo que, aunque necesarias para terminar de comentar esta etapa del desarrollo, apenas guardan relación entre ellas Estructuras Como se comentó en el apartado sobre módulos (punto 4.2.1), el controlador puede recibir un parámetro durante la carga del módulo: este parámetro indicaba cuántas instancias del dispositivo deberían crearse. Puesto que el número de instancias nunca es fijo entre una carga del módulo y otra, es necesario poder gestionar estas instancias dentro del código: concretamente habrá una estructura del tipo rollback dev (ver listado 4.28) por cada instancia. Para este tipo de problemática suelen emplearse listas enlazadas donde cada elemento de la lista es una instancia de la estructura deseada y, además, apunta al siguiente elemento. De hecho, Linux también provee de listas doblemente enlazadas mediante un tipo especial struct list head y sus funciones asociadas. La explicación a este soporte viene dada porque es un tipo muy común en los desarrollos software y existían muchas implementaciones en el núcleo, propias de cada desarrollador, utilizadas en sus contribuciones a Linux. En un determinado momento, los 57

70 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN desarrolladores de Linux acordaron crear un tipo estándar y las funciones necesarias para utilizarlo, para así unificar las distintas implementaciones, siendo así mucho más fácil corregir fallos y evitando código redundante dentro de Linux. Aunque el uso de una lista enlazada parece una solución correcta, no lo es completamente, al menos no con este problema. Puesto que se crean todas las estructuras asociadas a sus instancias correspondientes durante la carga del módulo y se eliminan conjuntamente, sin haber variaciones en su número durante todo su uso, es más simple y rápido usar un vector de estructuras que las contenga. Este vector se crea durante la carga y es destruido al descargar el módulo de memoria. Para acceder a cada instancia basta indexar con su minor en el vector y así se obtendrá su estructura rollback dev asociada. Listado 4.28: Estructura con información 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 después de CREATE), listo (después de RUN) o sincronizando (mientras se ejecuta el SYNC). La transición 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. Cuando se envía el comando SYNC, el estado cambia y no retorna a LISTO hasta que no ha terminado la sincronización de contenido. No hay comando ninguno para hacerle volver, de ahí el símbolo *. original str: cadena que representa al dispositivo del que sólo se leerán datos. original: apunta al dispositivo una vez abierto. escritura str: cadena que representa al dispositivo en el que se realizarán escrituras además de lecturas sobre los datos escritos. 58

71 4.2 Creación del dispositivo virtual Figura 4.1: Transición entre estados del controlador. escritura: apunta al dispositivo una vez abierto. disco: representa la instancia del dispositivo virtual desde el punto de vista del núcleo, es decir, 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: número de veces que ha sido abierto el volumen virtual. sectores bloque: puesto que el volumen virtual ha de contener los mismos sectores que el de lecturas u original, es necesario que también sepa el tamaño en sectores del bloque del dispositivo, puesto que el tamaño de las peticiones que le lleguen siempre será múltiplo de este valor. Es más, normalmente estarán alineadas de forma que empiecen en un bloque. sector0: suele haber una petición que no está alineada ni en el origen ni en el tamaño de bloque: la petición inicial. Cuando el código del sistema de ficheros monta la partición no sabe el tamaño de bloque hasta que no lo lee, normalmente del superbloque. Por seguridad, lanzará una petición de lectura conservadora, que puede no encajar con el tamaño de bloque de la partición, y luego, una vez sepa el tamaño correcto, es cuando procederá a realizar las peticiones correctamente. Para decirle al controlador que permita pasar esta petición inicial desalineada se le indica el sector del que puede leerse sin tener en cuenta las restricciones del tamaño de bloque. mapa info: almacena toda la información utilizada en la lógica de mapeo. Puesto que es durante la inicialización del módulo cuando se solicitan tantas instancias de esta estructura como dispositivos se quieren crear, es posible pedir la memoria sin tener en cuenta ningún tipo de restricciones: GFP KERNEL. 59

72 4.3. Lógica del mapeo DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN Tratamiento clásico de una petición E/S Como se comentó anteriormente, cuando un proceso quiere leer el contenido de un fichero, comunica su petición al sistema de ficheros encargado del dispositivo donde se halla el fichero. El sistema de ficheros la traducirá a una petición de acceso a determinados bloques del dispositivo, siempre que la información no estuviera ya en caché. Esta petición contendrá, entre otras cosas, información del sector al que ha de accederse dentro del dispositivo, el número de sectores a los que acceder, un campo que identifique el tipo de operación como lectura, una colección de páginas de memoria donde alojar el contenido leído, etc. Todo estos datos se encuentran dentro de una estructura denominada BIO o Block Input/Output (ver listado 4.30). Este BIO es creado y rellenado adecuadamente por el subsistema que necesita acceder al dispositivo, por ejemplo el sistema de ficheros Ext2, y es enviado a la cola del dispositivo. Mientras está en la cola, el planificador de E/S puede decidir combinar peticiones o reordenar la cola para optimizar el rendimiento del dispositivo. Cada vez que el dispositivo está desocupado, el controlador lee una petición BIO de la cola y procede a satisfacerla. Una vez lo ha hecho, avisa al subsistema que envió la petición de que su operación ha sido completada para que pueda seguir como crea conveniente; mientras, el dispositivo toma otra petición de la cola e igualmente procede a tratarla. Para satisfacer una petición BIO, el controlador del dispositivo, una vez ha tomado una de su cola, hace lo siguiente: 1. Toma nota del sector inicial y del tipo de operación. 2. Dependiendo del tipo de operación: a) Si es una lectura: se irán leyendo del soporte los sectores, todos ellos consecutivos, y se irán almacenando en los bloques contenidos en los segmentos indicados por el BIO. b) Si es una escritura: se irán leyendo de los segmentos del BIO los bloques a medida que se quiera escribir su contenido en los sectores del dispositivo. 3. Una vez se termine la operación, haya sido completada satisfactoriamente o haya fallado en algún punto, el dispositivo le hará notar la situación al emisor del BIO. Se sobreentiende que, para leer o escribir en el dispositivo, el controlador tendrá que enviar los comandos adecuados al hardware. La unidad mínima de transferencia de un dispositivo es el sector de 512 bytes, de forma que las peticiones deben indicar la cantidad de sectores que requieren. Pero el núcleo impone que las transferencias sean de más sectores, concretamente del tamaño de bloque del sistema de ficheros del dispositivo, porque es probable que los siguientes datos que se necesiten sean adyacentes a los actuales. Este bloque agrupa un múltiplo de sectores que debe cumplir las siguientes condiciones: 60

73 4.3 Lógica del mapeo Figura 4.2: Bloques, segmentos y páginas. Ser una potencia de dos. Debe ser inferior o igual al tamaño de página, normalmente 4096 bytes. Debe ser múltiplo del tamaño de sector: 512 bytes. Por tanto, los tamaños de bloque permitidos son 512, 1024, 2048 y El tamaño de bloque depende del sistema de ficheros del dispositivo. De hecho, si hay varios sistemas de ficheros en distintas particiones de un dispositivo, cada partición podría usar un tamaño de bloque distinto para las transferencias. En el caso de que se haga la lectura de datos en bruto de un dispositivo, sin pasar por un sistema de ficheros, se toma el mayor valor: 4 KiB, el tamaño de página. Además, los bloques adyacentes dentro de un página, a la hora de participar en una transferencia, son agrupados en segmentos y estos no pueden abarcar más allá de su página. En la figura 4.2 se puede ver una página 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 por un segmento diferente. # 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 ; Listado 4.29: Estructura de un bio vec. 61

74 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN } ; u n s i g n e d i n t b v o f f s e t ; bv page: página de memoria asociada. bv len: longitud del segmento dentro de la página. bv offset: desplazamiento dentro de la página donde comienza el segmento. La petición BIO apunta a un vector de estructuras bio vec (ver listado 4.29) donde cada estructura representa un segmento dentro de una página que debe ser utilizado para almacenar o leer los bloques implicados en la transferencia. El segmento está delimitado por los campos bv offset (origen) y bv len (longitud) dentro de cada página. Sumando los tamaños de cada segmento de cada página se obtendrá un valor igual al tamaño en bytes de los sectores a transferir. Figura 4.3: Relación de los distintos BIO con sus segmentos y bloques. Para que sea más fácil entender cómo se crean los BIO y su relación con los bloques, segmentos y páginas se mostrará un ejemplo en el que se necesita leer 9000 bytes de un fichero F. 62

75 4.3 Lógica del mapeo 1. A través de la llamada al sistema sys read llega una petición de lectura de los primeros 9000 bytes del fichero F. 2. Linux considera que un fichero está compuesto por páginas, de forma que, ante una petición de acceso a un intervalo de un fichero, traduce esa petición al conjunto de páginas que deberían almacenar ese contenido. El tamaño de página es de 4096 bytes, así que la lectura requerirá de tres páginas: = 9000 bytes. Al ser los primeros 9000 bytes, las páginas necesarias serán las tres primeras del fichero. 3. El sistema de ficheros consulta en la caché de páginas, mediante el identificador del fichero, si están disponibles esas tres páginas de una lectura o acceso anterior. Se supondrá que no se encuentran en la caché las páginas solicitadas. 4. El sistema de ficheros necesita obtener esas páginas, así que deberá acceder al dispositivo de bloques subyacente. Por tanto, para rellenar adecuadamente cada página, deberá leer los bloques que almacenan esos 9000 bytes y almacenarlos en las tres páginas. Suponiendo un tamaño de bloque de 1024 bytes, el SF elabora una lista con los bloques de datos implicados en la operación consultando los primeros doce 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 proximidad espacial 12 y, además, así termina de rellenar la última página con datos. 5. Para poder optimizar el rendimiento, Linux agrupa los accesos de forma que cada BIO 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 Cada bloque que va a ser leído tiene un lugar asignado dentro de alguna de las tres páginas. Por tanto, cada BIO debe tener una lista de estructuras bio vec que describa los segmentos implicados. Los segmentos agrupan, dentro de una misma página, bloques que vayan a ser tratados por la misma petición BIO. Si el hardware tiene soporte para transferencias DMA 13 scatter-gather 14, cada BIO podrá hacer referencia a distintos segmentos; si no, cada BIO deberá tratar, de uno en uno, los segmentos. 12 Es bastante probable que si se ha accedido a un bloque n, alguno de los siguientes bloques en ser accedido sea n El acceso directo a memoria, del inglés Direct Memory Access, es un tipo de transferencia entre un dispositivo y la memoria del sistema en la cual no es necesaria la intervención del procesador. 14 En las transferencias clásicas 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

76 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN 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 página dos. b) BIO 2: un segmento que engloba todos los bloques en la página uno y otro segmento que engloba el bloque 84 en la página dos. La página uno junto con el principio de la página dos no podrían formar un segmento único por la restricción de que los segmentos deben estar contenidos por las páginas. c) BIO 3: un segmento que engloba los bloques 100 y 101 de la página dos y otro segmento que engloba el bloque 102 de la página tres. Puesto que hay bloques dispersos en dos páginas no es posible tratar la petición como si fuera un único segmento. d) BIO 4: un segmento que engloba los bloques 110, 111 y 112 de la página tres. A continuación, se explicará la base de las peticiones: la estructura BIO (sólo los campos importantes). # i n c l u d e <l i n u x / b i o. h> Listado 4.30: Estructura BIO. 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 l ong b i f l a g s ; u n s i g n e d l ong 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 ; void 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 dará comienzo la transferencia. bi bdev: dispositivo del que se leerá o escribirá. bi flags: almacena el estado de la petición. bi rw: tipo de operación que realizar: lectura o escritura. bi vcnt: número de segmentos del campo bi io vec. bi idx: índice dentro del vector de segmentos. Puesto que las peticiones pueden no tratarse enteramente mediante una sola pasada, se anotará en este campo cuál es el siguiente segmento al que acceder. En el siguiente intento para completar la petición se partirá desde este segmento. 64

77 4.3 Lógica del mapeo bi size: número de bytes por transferir aún. Al igual que con el campo anterior, si no se ha completado la petición entonces este campo indicará los bytes restantes. Una vez sea cero, se dará por satisfecha la petición, siempre que no se produzca un error antes. bi io vec: almacena un vector de estructuras bio vec donde cada una de ellas ofrece información de un segmento que deberá ser utilizado para realizar la transferencia pedida. bi end io: puntero a la función encargada de avisar al emisor de la petición BIO de que esta ha sido completada, sea con error o no. bi cnt: contador de referencias de la estructura. Evita que se elimine o libere la estructura mientras está en uso. bi private: campo que utilizará el emisor de la petición como crea conveniente. bi destructor: puntero a la función encargada de liberar la memoria usada por la estructura BIO. Es importante recalcar, una vez más, por qué no tiene sentido una cola real en el dispositivo que está siendo desarrollado: el dispositivo es virtual y no sirve de nada. Tratar de alguna forma las peticiones que a él llegan es desperdiciar tiempo de procesador y memoria. Actúa como una estación de paso donde tener constancia de las peticiones y poder acceder a ellas para su posterior tratamiento Tratamiento de la petición de E/S por parte de la solución La parte de tratamiento y manipulación de la petición BIO se da una vez ha llegado a la cola del dispositivo. Éste es avisado mediante la ejecución de la función mapeo map request, como se vio al asociar esa función a la cola en el punto Para poder discernir qué bloques se encuentran en el dispositivo de lecturas (DL) y cuáles en el de escrituras (DE), se utiliza un vector que hará las labores de mapa. El mapa o vector contiene posiciones de bloque, de forma que, al indexar un número de bloque, se obtiene uno de los siguientes valores: Una constante predefinida que indica que no se ha mapeado ese bloque y que denominaremos NO MAPEADO. Obtener ese valor significa que ese mismo número de bloque debe buscarse en DL. Un bloque, situado en el dispositivo de escrituras, donde se almacena realmente el bloque solicitado. En este caso el bloque dado, correspondiente al dispositivo virtual, debe sustituirse por el bloque obtenido al indexar y redirigir la operación sobre ese bloque a DE. 65

78 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN Por tanto, el tamaño del vector es el tamaño en bloques del dispositivo virtual; tamaño que es el mismo que el de DL, puesto que el tamaño del dispositivo virtual se tomó de DL durante la inicialización del dispositivo. Cuando llegue una petición, se anotarán los bloques implicados en la transferencia y se indexarán sus posiciones en el mapa, obteniendo las posiciones correspondientes en DE o DL. Los bloques implicados en la transferencia se pueden deducir mediante: el sector inicial indicado por bi sector más el número de bloques por transferir, obtenidos al dividir el volumen de bytes indicado por bi size entre el tamaño de bloque. Al aplicar esa región sobre el mapa se obtienen las subzonas. Cada subzona representa un conjunto de bloques que pueden ser procesados como una petición BIO. Si se obtiene una única subzona, se puede reaprovechar la petición BIO original, de forma que, retocando los campos necesarios, se procese correctamente. Si la petición BIO original da lugar a varias subzonas, será necesario fabricar peticiones BIO propias, donde cada una de ellas se encargue de procesar cada subzona. Una vez terminen esas peticiones o minibio 15 se dará por satisfecha la petición BIO original y se avisará al emisor de la misma. Una subzona es detectada, cuando, al traducir mediante el mapa los bloques implicados 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 mapa son consecutivos y llegan a dar con un bloque no consecutivo o NO MAPEADO. 15 Un minibio es un BIO normal pero que se encarga de satisfacer una porción del BIO original representada por una subzona. 66

79 4.3 Lógica del mapeo Figura 4.5: Ejemplo de subzona: bloques mapeados consecutivos y no consecutivos. Habrá veces en que la petición vaya a un sólo dispositivo, el de escrituras, pero, aun así, deba ser fragmentada. La razón más probable es que los bloques implicados en la operación no sean consecutivos en el dispositivo destino. Por ejemplo: 1. Recién inicializado el dispositivo virtual, se deciden leer los bloques 0 y 8 del mismo, lo que hará que se lean del dispositivo de lecturas. 2. Una vez leídos, son modificados y escritos a disco. Al hacerlo, estas escrituras se redirigirán a los bloques 0 y 1 del dispositivo de escrituras, puesto que son los primeros bloques libres disponibles. 3. Se decide leer el bloque 2 del dispositivo virtual. Esta lectura se transforma en una lectura del mismo bloque, pero del dispositivo de lecturas. 4. Después de leído, es modificado y escrito a disco. El bloque que ocupará será el siguiente disponible del dispositivo de escrituras: el bloque Si se lanza una operación de lectura de los bloques 0 y 1, ésta será dirigida hacia el dispositivo de escrituras y fragmentada, puesto que, aunque son consecutivas en el dispositivo virtual (0 y 1), no lo son en el de escrituras (0 y 2), dando lugar a dos subzonas que serán tratadas mediante dos minibio. Una vez explicado el funcionamiento de las subzonas y cómo se producen, se mostrará a continuación cómo se trata la petición una vez llega a la cola del dispositivo: 1. Se calculan las subzonas implicadas mediante el mapa y los campos de la petición BIO. 2. Dependiendo del tipo de operación: a) Se trata de una lectura: 1) La lectura comienza en un bloque no modificado y abarca bloques no modificados (una única subzona): se envía la petición, sin modificar, al dispositivo de lecturas. 2) La lectura se realiza sobre una subzona modificada: se envía la petición al dispositivo de escrituras, ajustando el sector de inicio para que sea correcto. 67

80 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN 3) La lectura se realiza sobre varias subzonas: unas no están mapeadas y otras sí. El procedimiento consiste en fragmentar la petición BIO en tantos otros minibio como subzonas haya. El sector de inicio, la cantidad de bloques que transferir y demás valores de la petición son ajustados para cada una de las peticiones. Se enviarán unos minibio al dispositivo de lecturas y otros al de escrituras. b) Se trata de una escritura: 1) La escritura es sobre un bloque no modificado y abarca una sola subzona. Se usan los primeros bloques libres del dispositivo de escrituras para almacenar el contenido de la petición, por lo que la petición es redirigida a este dispositivo. Además, se actualiza el vector de mapeo o mapa de forma que subsiguientes accesos a los mismos bloques del dispositivo virtual redirijan a los mismos bloques del dispositivo de escrituras. 2) La escritura es sobre una única subzona ya mapeada: se modifica la petición BIO para que acceda al dispositivo de escrituras y se corrige el sector inicial con el valor correcto obtenido al indexar en el mapa. 3) La escritura es sobre varias subzonas: unas no están mapeadas y otras sí. Al igual que en la lectura, es necesario fragmentar la petición mediante minibio en tantas partes como subzonas haya. Las subzonas ya mapeadas tomarán el sector inicial correspondiente del mapa y serán enviadas al dispositivo de escrituras. Las no mapeadas tendrán que localizar bloques libres y ser redirigidas a ellos además de actualizar sus posiciones en el mapa. Enviar una petición a un dispositivo u otro supone ajustar el campo bi bdev para que haga referencia al dispositivo correspondiente. Para aportar más claridad de todo el proceso se mostrará un ejemplo: 1. El dispositivo virtual acaba de crearse. El dispositivo DL se encargará de las lecturas, mientras que DE se hará cargo de las escrituras y de las lecturas sobre datos modificados. 2. Llega una petición de lectura del bloque 0. Se comprueba al indexar el número de bloque en el mapa que este bloque no ha sido mapeado, es decir, el valor devuelto es NO MAPEADO. Se envía la petición, sin cambios, mismo bloque y cantidad de bloques a leer, a DL. Usando una notación particular se dirá que: [0]:NO MAPEADO Llega una petición de escritura del bloque 0. Se comprueba igualmente y se observa que no ha sido mapeado. Por tanto, al ser una escritura y no tener bloque asignado en DE, se localiza el primero libre del mismo: el bloque 0. Se actualiza el mapa de forma que refleje esta situación: si se indexa la posición 0, se obtiene el valor 0. Se reduce el número de bloques libres y se redirige la petición a DE manteniendo el mismo sector de inicio ([0]:0). 16 Entre corchetes va el valor a indexar y a continuación de los dos puntos el valor que se obtendrá. 68

81 4.3 Lógica del mapeo 4. Llega una petición de lectura del bloque 4. Se comprueba que no está mapeado, así que se redirige a DL ([4]:NO MAPEADO). 5. Llega una petición de escritura del bloque 4. Se comprueba que no está mapeado, así que se le da el siguiente bloque libre de DE, el 1, y se redirige la petición a ese bloque ([4]:1). 6. Llega una petición de lectura del bloque 1 ([1]:NO MAPEADO), y se redirige a DL. Figura 4.6: Fragmentación de un BIO en tres minibio. 7. Llega una petición de escritura del bloque 1 que es redirigido a DE. Como no tiene ninguno asignado ([1]:NO MAPEADO) se le da el primero libre, que resulta ser el bloque 2 ([1]:2). 8. El estado actual del mapa es el siguiente: [0]:0, [1]:2 y [4]:1. El resto de posiciones contienen el valor NO MAPEADO. 9. Llega una petición 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 son consecutivos en DE, por lo que deberá fragmentarse la petición BIO en tres: una se 69

82 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN encargará de ir a DL y acceder al bloque 2; a DE irán dos: una al bloque 0 y otra al bloque Llega una petición 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 dentro de DE, así que se le da el primero libre: 3 ([2]:3). Ahora se intenta completar la petición, aunque deberá fragmentarse en dos, pues dos son las subzonas. Todas las peticiones irán a DE, pero una escribirá en el bloque 0 y la otra escribirá en los bloques 1 y 2, los cuales, al ser consecutivos en DE, pueden ser encapsulados en el mismo minibio Modificación y/o fragmentación de una petición BIO Toda petición BIO que cubra varias subzonas debe ser fragmentada tantas veces como subzonas haya. Cada fragmento será gestionado por medio de una nueva petición BIO, cuyos campos deberán ser inicializados o adaptados. La función bio alloc bioset (ver punto 4.32) devuelve una estructura BIO parcialmente inicializada, cuyos campos terminarán de ser inicializados mediantes los valores de la petición BIO original (con la función bio clone es posible, además, clonar el contenido de un BIO en otro). Así, sólo será necesario ajustar aquellos campos que hagan falta. Figura 4.7: Ejemplo de BIO con tres segmentos que ocupan cada uno una página completamente y que serán utilizados en la transferencia. Los campos simples, como el sector inicial o el número de bloques que transferir, son fácilmente extrapolables a cada nuevo BIO, ya que basta con deducirlos a partir de la petición BIO inicial. En cambio, los segmentos que indican las páginas que almacenarán (lectura) o almacenan (escritura) el contenido requieren de una adaptación especial. Partiendo del BIO de la figura 4.7 y dependiendo de cuántas subzonas haya y cuántos segmentos necesiten, pueden ocurrir tres situaciones: 70

83 4.3 Lógica del mapeo La subzona se compone de varios segmentos: es necesario corregir el campo bi idx para que apunte al segmento correspondiente al bloque que se comenzará a transferir. Además, la lista de segmentos será un subconjunto de la original reduciendo el campo bi vcnt. También podría ser necesario corregir el tamaño del último segmento, si no se va a utilizar completamente: si el número de bloques que transferir no ocupa el segmento entero, es necesario reducir el campo bv len al valor exacto de bytes que serán necesarios. Es importante recalcar que puede ser, o no, necesario reducir este campo, pero nunca tendrá que ser agrandado. Figura 4.8: Creación 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 tendrá sólo un segmento, el que corresponda dentro de la estructura BIO original, y además deberá 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 necesario ajustar también el campo bv offset del primer segmento que utilizar en esta transferencia. Figura 4.9: Creación de un BIO que requiere de medio segmento de los disponibles. 71

84 DESARROLLO E IMPLEMENTACIÓN DE LA SOLUCIÓN La subzona es la última: el nuevo BIO copiará la estructura de segmentos del BIO original y sólo deberá ajustar el valor bi idx para que comience la transferencia en el segmento adecuado. Figura 4.10: Creación de un BIO que requiere del último segmento disponible. Una vez se han creado estos BIO que harán la labor del original, se envían al dispositivo adecuado ajustando el campo bi bdev y utilizando la función generic make request. Al ser BIO propios de nuestro controlador, es necesario tener cierto control sobre los mismos. Lo primero es ajustar el campo bi end io para que apunten a una función propia donde hagan constar que han terminado. Así, mediante esta función y una estructura io info creada a tal efecto (ver listado 4.31) que relacione la petición BIO original con los fragmentos creados, se podrá deducir cuándo se ha completado la petición original por medio 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 algún error con cualquiera de los minibio generados a partir del original. bio: petición BIO original. contador: indica cuántos minibio quedan por terminar. 72

85 4.3 Lógica del mapeo Finalmente, queda el problema de gestionar la carencia de bloques libres en el dispositivo de escrituras a los cuales redireccionar las escrituras. Llega un momento en el que este depósito de bloques libres se agota y no es posible mapear nuevos bloques. Obviamente, este problema no afecta a aquellas peticiones que intenten acceder a bloques ya mapeados en el dispositivo de escrituras. Puesto que no hay sitio donde escribir estas nuevas peticiones y el contenido de las escrituras no es crítico (al reiniciar el sistema se perderán), se rechaza la petición BIO mediante un error genérico de E/S: EIO. Como facilidad para con el usuario, se le avisa un tiempo antes de que quede vacía la lista 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: Manipulación 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 ) ; void 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 ) ; void 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 ) ; void 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

86

87 Capítulo 5 CARACTERÍSTICAS OPCIONALES 5.1. Introducción En este capítulo se explicarán algunos objetivos opcionales desarrollados. La mayoría de ellos supone mejoras en rendimiento, como un menor consumo de memoria o el uso de cachés de objetos, o nuevas características, como son la posibilidad de sincronizar el contenido del dispositivo de escrituras con el de lecturas o poder integrar el dispositivo virtual dentro del sistema make 1 de Linux Consumo de memoria Tal y como se explicó en el capítulo anterior, el mapa utilizado para redirigir las peticiones de E/S a los distintos dispositivos es un vector cuyo tamaño es el del número de bloques del dispositivo de lecturas. Además, cada posición del vector almacena una posición de un sector. En IA-32, el tamaño del tipo sector t definido por Linux ocupa 32 bits, mientras que en AMD64 su tamaño es de 64 bits. Por ejemplo, un dispositivo de lecturas de 40 GiB con un tamaño de bloque de 4 KiB en IA-32: 1. Necesitaría un vector de ( bytes) / ( bytes por bloque) = posiciones o bloques. 2. Cada posición necesita almacenar un número de sector de 32 bits o 4 bytes. 3. En total, el vector necesita = 40 MiB de datos en espacio del núcleo. 40 MiB es una cifra respetable, pero si además se trabaja en una arquitectura AMD64, donde se dobla el tamaño del sector, el tamaño en memoria del mapa sería de 80 MiB. Es importante reducir esta cifra, así que el primer paso ha sido fijar el tamaño del sector a 1 Make es una herramienta utilizada en la construcción automatizada de aplicaciones. 75

88 CARACTERÍSTICAS OPCIONALES 32 bits. Esto limita el tamaño de la unidad a 2 TiB 2, lo que es un valor aceptable para las necesidades de este proyecto. El siguiente paso lógico consiste en reducir o variar la estructura del mapa. La opción idónea es la misma que se utiliza para almacenar los marcos de páginas de un proceso: una tabla de páginas 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 bloques mapeados, se utilizará un vector más pequeño, donde cada posición apuntará a su vez a otro vector, vector que almacenará los bloques mapeados. A simple vista parece que consumiría más por el nivel de indirección añadido. Pero esto no es así, ya que, mientras no haya un bloque mapeado en el vector de segundo nivel, este no existirá ni ocupará memoria. Por ejemplo, observando la figura 5.1 se puede ver cómo ya han sido mapeados al dispositivo de escrituras los bloques 0, 1 y Por el contrario, los bloques del 1024 al 2047 no han sido mapeados, así que no es necesario tener un vector encargado de mapear esa región, al menos por ahora. Si más tarde hiciese falta mapear uno de esos bloques, por ejemplo el 1024, entonces es cuando se pediría memoria para esa región y, además, el vector que hace de mapa apuntaría a ese vector más pequeño para todos los accesos a esa región. Los vectores de segundo nivel se forman mediante páginas de memoria de 4 KiB. Cuando resulta necesario asignar un vector nuevo al vector principal, se solicita la página y se modifica el vector principal para que apunte a ella. Al tener 4 KiB y almacenar cada cuatro bytes una posición de sector, es posible direccionar hasta 1024 posiciones de sector por vector secundario. Tomando como ejemplo el mismo dispositivo de 40 GiB con los mismos parámetros usado anteriormente, se obtendría el siguiente consumo de memoria: 2 (2 32 sectores * 512 bytes por sector) / (2 40 bytes por TiB). 76

89 5.3 Sincronización de dispositivos Máximo número de vectores de segundo nivel necesarios: posiciones / 2 10 posiciones por página = páginas de 4 KiB. Es decir, 40 MiB, al igual que el vector clásico del método anterior. Los resultados coinciden, puesto que la concatenación de todos los vectores secundarios daría lugar al vector único utilizado hasta ahora. Consumo inicial de memoria: páginas direccionadas mediante un vector de punteros. En IA-32, cada puntero ocupa cuatro bytes, así que la memoria necesaria sería de bytes o 40 KiB. En AMD64, los punteros ocupan el doble, ocho bytes; por tanto, el consumo es de bytes u 80 KiB. Incremento en el consumo de memoria de 4 KiB por cada nuevo vector de segundo nivel. Consumo máximo de memoria: el consumo máximo se alcanza al tener en memoria todos los vectores secundarios más el principal. Visto el mínimo impacto del vector principal, el consumo máximo sería igual al del modelo de vector único. La mejora de este modelo se da desde el primero momento, pues no necesita del vector único en memoria para trabajar. Al contrario, según aumenten las necesidades irá pidiendo páginas de memoria en vez de solicitarlas todas inicialmente. En el peor de los casos, con todos los bloques mapeados, el consumo será prácticamente el mismo que el del modelo anterior. Como beneficio adicional, en aquellos casos donde la capacidad del dispositivo de lecturas sobrepase con mucho al de escrituras, el vector único despilfarrará memoria, pues nunca podrán mapearse todos los bloques. Con este segundo modelo, más ahorrativo y gradual, cuando se llegue al tope de ocupación del dispositivo de escrituras, se dejarán de solicitar páginas y, por tanto, el consumo de memoria se estancará en unos valores razonables. También resulta útil, independientemente del tamaño de los dispositivos, cuando el uso que se haga del sistema sea pequeño, es decir, no se mapeen muchos bloques Sincronización de dispositivos La 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, puede existir la necesidad de querer mantener los cambios, pero, tal y como se ha desarrollado el sistema, no es posible. Para atender esa necesidad se desarrolló un comando ioctl, denominado RBD SYNC, cuya labor es mezclar adecuadamente los contenidos almacenados en DE con los de DL, evitando así la pérdida de la información nueva. El desarrollo de una función que cubra ese problema es muy simple; basta con copiar la información mapeada de DE en aquellas posiciones de DL a las que inicialmente iban dirigidas, aunque con dos condiciones: no debe haber más escrituras en DE mientras dure la operación y el sistema debe tener un estado consistente antes de comenzar. 77

90 CARACTERÍSTICAS OPCIONALES Estas dos restricciones se cumplen de la siguiente forma: Estado consistente: el usuario debe desmontar el sistema de ficheros montado sobre el dispositivo virtual o, si no fuera posible, forzar que quede montado pero con permisos exclusivamente de lectura. Cualquiera de estas dos opciones forzará las escritura en disco de todas las peticiones pendientes, sean datos o metadatos, y deshabilitará las escrituras en el soporte. Deshabilitar las escrituras: aunque el paso previo ya se ha encargado de esa tarea, es posible conseguir un nivel más de confianza rechazando, desde dentro del código del dispositivo que atiende las peticiones de E/S, todas aquellas peticiones que deseen realizar una escritura. A nivel de implementación, el controlador crea un BIO encargado de leer una zona mapeada en DE y, con los mismos segmentos que contienen la información transferida, crear otra petición BIO que escribirá los datos en DL. Este proceso se repite para todos aquellos 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 hay sectores mapeados y se permiten las escrituras de nuevo. Igualmente, el dispositivo de escrituras tiene ahora todos sus bloques disponibles Estadísticas de acceso al dispositivo Desde 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 versión para la rama estable y para la de desarrollo 3, se decidió mejorar este sistema y hacerlo más exhaustivo. Desgraciadamente, apenas hay información sobre cómo usar este sistema y, por tanto, es necesario bucear en los fuentes del núcleo. Un buen punto de partida antes de analizar los fuentes es el documento iostats.txt dentro del directorio de documentación del núcleo. El documento iostats.txt describe los campos que se obtienen al leer el fichero virtual /proc/diskstats 4 y que contienen las estadísticas recolectadas para los diferentes dispositivos de bloques del sistema y sus particiones si las tuvieran. Estos mismos datos son accesibles mediante sysfs 5, aunque sólo muestran información del dispositivo de bloques que se está 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 que la información de hda se hallaría en /sys/hda/stat (listado 5.2). 3 Más información sobre el sistema de numeración de Linux: wiki/linux kernel#version numbering 4 Se asume que el sistema de ficheros proc se encuentra montado en /proc. 5 Al igual que para proc, se asume que sysfs se encuentra montado en /sys. 78

91 5.4 Estadísticas de acceso al dispositivo Listado 5.1: Ejemplo de fichero /proc/diskstats. 3 0 hda hda hdb hdb Listado 5.2: Ejemplo de fichero /sys/block/hda/stat Además, en cada subdirectorio de /sys/hda que correspondiese a una partición habría un fichero stat (listado 5.3) con las estadísticas de esa partición en concreto. Listado 5.3: Ejemplo de fichero /sys/block/hda/hda1/stat Estructura del fichero diskstats La estructura de los campos para un disco sería la siguiente: 1. Número de lecturas completadas. 2. Número de lecturas combinadas: son lecturas adyacentes en el disco y que, por tanto, se pueden combinar en una única petición. Por ejemplo, dos lecturas de 4 KiB de dos zonas adyacentes en el disco darán lugar a una lectura de 8 KiB. Este campo indica cuán a menudo se ha realizado este tipo de combinación. 3. Número de sectores leídos. 4. Tiempo en milisegundos invertido en lecturas: este campo abarca desde que se lanza la petición con make request() hasta que end that request last() la da por terminada. 5. Número de escrituras completadas. 6. Número de escrituras combinadas: igual que el punto 2, pero relativo a las escrituras. 7. Número de sectores escritos. 8. Tiempo en milisegundos invertido en escrituras: igual que el punto 4, pero relativo a las escrituras. 9. Número de operaciones de E/S en proceso: es el único campo que debe valer casi constantemente cero. Se incrementa cuando se encola una petición en la cola de peticiones adecuada y se decrementa cuando concluye la petición. 79

92 CARACTERÍSTICAS OPCIONALES 10. Tiempo en milisegundos invertido en operaciones de E/S: este campo se incrementa mientras haya alguna operación de E/S en proceso. 11. Tiempo total en milisegundos invertido en E/S: a diferencia del campo anterior, este campo refleja la suma total del tiempo invertido en satisfacer cada petición 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 secciones críticas para evitar cuellos de botella. A cambio, se pierde algo de precisión si hay accesos concurrentes a estos campos Estructura disk stats Ya que el fichero /proc/diskstats informa de los valores que se quieren medir, es lógico comenzar a explorar los fuentes del núcleo buscando el punto donde se crea dicho fichero. Este fichero virtual se ha creado, junto con muchos más que aportan todo tipo de información sobre Linux, en fs/proc/proc misc.c:proc misc init. Y la función encargada de volcar las estadísticas es block/genhd.c:diskstats show. Dentro de esta función se observa cómo 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 la estructura gendisk que describe al disco. Por tanto, la estructura disk stats es la encargada de almacenar las estadísticas de cada disco del sistema. La definición de la estructura disk stats se puede ver en el listado 5.4. # i n c l u d e <l i n u x / genhd. h> Listado 5.4: Estructura disk stats. s t r u c t d i s k s t a t s { u n s i g n e d l ong s e c t o r s [ 2 ] ; / READs and WRITEs / u n s i g n e d l ong i o s [ 2 ] ; u n s i g n e d l ong merges [ 2 ] ; u n s i g n e d l ong t i c k s [ 2 ] ; u n s i g n e d l ong i o t i c k s ; u n s i g n e d l ong t i m e i n q u e u e ; } ; Es fácil establecer una correlación entre los campos de esta estructura y los de la estructura del fichero diskstats descrita en el punto anterior: sectors: vector de dos posiciones que contiene los sectores leídos y escritos. Se corresponde con los campos tres y siete del punto anterior. ios: vector de dos posiciones que contiene el número de peticiones de lectura y escritura realizadas. Se corresponde con los campos uno y cinco del punto anterior. merges: vector de dos posiciones que contiene el número de peticiones de lectura y escritura que se han combinado. Se corresponde con los campos dos y seis del punto anterior. 80

93 5.4 Estadísticas de acceso al dispositivo ticks: vector de dos posiciones que contiene los jiffies utilizados en satisfacer las operaciones de lectura y escritura. Se corresponde con los campos cuatro y ocho del punto anterior. io ticks: almacena los jiffies utilizados en operaciones de E/S. Se corresponde con el campo diez del punto anterior. time in queue: almacena la suma total de los jiffies utilizados para realizar cada una de las 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 posición cero corresponde a la lectura y la posición uno a la escritura. Los jiffies 6 son realmente los tics del reloj del sistema y se suelen usar como medida de tiempo en los sistemas operativos. Por tanto, para mostrar estos valores al usuario es necesario convertirlos previamente a milisegundos mediante la función jiffies to msecs. La parte del núcleo que trata las colas de peticiones de los dispositivos también se encarga de actualizar estos contadores. Para ello, analiza la petición e incrementa los contadores correspondientes. Esto no sucede con los dispositivos virtuales ya que no suelen tener colas de peticiones al uso, al carecer de un dispositivo físico al que enviar las peticiones. En nuestro caso, cuando llega una petición, 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 actualizan los contadores y es necesario hacerlo manualmente por medio de las macros que ofrece Linux Macro disk stat add La macro disk stat add se encarga de incrementar el contador indicado en una cantidad determinada. Su definición se puede ver en el listado 5.5. # i n c l u d e <l i n u x / genhd. h> Listado 5.5: Función disk stat add. d i s k s t a t a d d ( gendiskp, 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 sumará al contador

94 CARACTERÍSTICAS OPCIONALES Esta macro se utiliza para modificar el contador sectors (ver listado 5.6) que se encarga de anotar el número de sectores leídos y escritos en el dispositivo. Listado 5.6: Actualización de estadísticas. i n t mapeo make request ( 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 cceso / 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 serán actualizados nunca. El motivo es el siguiente: las peticiones que es necesario fragmentar y reenviar, una vez han sido satisfechas, vuelven al código del controlador, siendo muy fácil indicar el tiempo invertido por cada petición. Pero hay peticiones que no es necesario fragmentar y, por tanto, nunca volverán al código del controlador; esto impide que se pueda contabilizar el tiempo que han empleado, a no ser que se sustituya la función de finalización del BIO bio->bi end io por una propia. Esta función actualizaría los contadores y procedería a invocar la función original sustituida. Los inconvenientes son más complejidad en el código y una penalización en el tiempo necesario para el tratamiento de estas peticiones. Por tanto, se ha desechado la idea de actualizar todos estos contadores que se encargan de medir de alguna forma el tiempo empleado en el dispositivo Macro disk stat inc La macro disk stat inc es una particularización de la macro anterior. Su labor es incrementar siempre en uno el valor del contador indicado. Su definición se puede ver en el listado 5.7. # 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 ( gendiskp, f i e l d ) Listado 5.7: Función disk stat inc. gendiskp: estructura gendisk que describe el dispositivo. field: el campo de la estructura disk stats que se incrementará en uno. Esta macro se utiliza para modificar el contador ios (ver listado 5.6) que se encarga de anotar el número de peticiones de lectura y escritura realizadas en el dispositivo. Tampoco se actualizará el campo merges. La razón tras esta decisión es que las peticiones no se combinan nunca, pues siempre deben traducirse y posiblemente fragmentarse 82

95 5.5 Soporte para blktrace en peticiones más pequeñas que se redirigen a los dispositivos adecuados. En las colas de esos dispositivos es donde se combinarán las peticiones que hubiera, si fuera necesario. Esta labor la realizaría el gestor de colas de dispositivos de Linux Soporte para blktrace La herramienta blktrace 7, desarrollada por Jens Axboe, permite observar lo que sucede en la capa de E/S de bloques, concretamente cómo se tratan y resuelven las peticiones de E/S enviadas. # i n c l u d e <l i n u x / b l k t r a c e a p i. h> Listado 5.8: Funciones de blktrace. void 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 ) ; void 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 añadir. dev: dispositivo que procesará el BIO. from: sector original del BIO. to: sector al que se ha mapeado el BIO. Aunque hay más funciones disponibles para anotar las trazas, se ha decidido mostrar aquellas 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 dispositivo que sí tratará la petición. Así que las trazas que hay que anotar serán aquellas que, o bien expresen la operación de mapeo, o bien anoten la finalización de un BIO por medio de sus minibio. Para aquellas peticiones que son mapeadas se utiliza la función blk add trace remap. Los parámetros importantes son los relativos a los sectores: cuál era el sector original y a cuál se ha decidido mapear el BIO

96 CARACTERÍSTICAS OPCIONALES 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 request ( 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 ), bio, 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, bio >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 void 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, bool 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 ), bio, io >bio >bi bdev >bd dev, s e c t o r o r i g i n a l, bio >b i s e c t o r ) ;... } Cuando es necesario fragmentar un BIO en varios minibio por abarcar varias subzonas, se espera a la finalización de todos los minibio relacionados con ese BIO. Una vez sucede esto, se puede avisar al emisor del BIO de que éste ha sido completado. Para añadir esta información como traza se usa la función blk add trace bio, indicando mediante el parámetro what, el tipo de traza que se está anotando. El valor usado es BLK TA COMPLETE. Listado 5.10: Uso de blk add trace bio. s t a t i c void 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 >cola, io >bio, BLK TA COMPLETE) ;... } 5.6. Caché de objetos Linux implementa cachés o almacenes de aquellos objetos que suelan ser reutilizados a menudo. Tómese como ejemplo el caso de los BIO, que constantemente están siendo creados, procesados y eliminados. Cada vez que se quiere enviar una petición de E/S es necesario pedir la estructura al núcleo, para que la inicialice correctamente. El núcleo, para no estar pidiendo y liberando memoria constantemente, crea un conjunto de estructuras BIO que irá sirviendo a aquellos que las necesiten. Una vez terminen de usar la 84

97 5.6 Caché de objetos estructura, esta es devuelta al núcleo, aunque no liberada por éste. Simplemente se deja en memoria hasta que vuelva a ser necesaria, en cuyo caso se reinicializarán sus campos y se entregará como si hubiera sido creada para esa ocasión. Aunque el núcleo ya tiene su propia caché o almacén de BIO, no está de más que el controlador tenga el suyo propio. Este almacén resultaría beneficioso, ya que la posibilidad de que haya que fragmentar un BIO en varios minibio es muy alta y, por cada minibio, haría falta una estructura BIO. Linux tiene en cuenta esta necesidad y permite definir una caché de objetos BIO: La función bioset create se encarga de crear el conjunto necesario de BIO. Es necesario indicarle a la función el número de BIO y el número de segmentos que se quieren tener disponibles. Es necesario indicar el número de segmentos, ya que los BIO dependen, en gran medida, de estos para las transferencias. De nada serviría tener 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 BIO preasignados. Una vez ha sido creado el conjunto de BIO, se podrá disponer de ellos mediante la función bio alloc bioset, indicando el número de segmentos que se requieren para el BIO. Finalmente, se devuelve el BIO y los segmentos al almacén mediante la función bio free. # i n c l u d e <l i n u x / b i o. h> Listado 5.11: Gestión de la caché de BIO. 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 t b v e c p o o l s i z e ) ; void 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 ) ; void 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 ) Además de los BIO, hay otra estructura, no definida en el núcleo, sino en el proyecto, que es utilizada a menudo por los mismo motivos que los expuestos anteriormente. La estructura io info es la encargada de enlazar el BIO original con los minibio que están realizando realmente la operación. Por tanto, por cada BIO fragmentado, es necesario tener una estructura de este tipo. Al ser una estructura propia de la solución, hay que usar unas funciones similares a las anteriores, pero más genéricas, diseñadas para dar el soporte de cachés a estructuras propias del programador. Las funciones disponibles son las siguientes: 85

98 CARACTERÍSTICAS OPCIONALES La función mempool create slab pool es la encargada de crear el almacén de estructuras. Recibe la estructura de la que crear múltiples copias y el número de copias que se desea tener siempre disponible. La función mempool destroy libera el espacio ocupado por todas las instancias, es decir, el almacén al completo. mempool alloc es la función utilizada para solicitar una instancia de las disponibles. Finalmente, mempool free retorna al almacén la estructura después de usada, para que esté disponible para quien la solicite. # i n c l u d e <l i n u x / mempool. h> Listado 5.12: Gestión de la caché de objetos. 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 ) void mempool destroy ( mempool t pool ) ; void mempool alloc ( mempool t pool, g f p t gfp mask ) ; void mempool free ( v oid element, mempool t pool ) ; Si se estudia la implementación de las funciones encargadas de crear la caché de BIO en Linux, se observará que actúan como una capa adicional, específica para BIO, situada encima de las funciones genéricas encargadas de crear y tratar el almacén de estructuras deseado Utilización de macros de Linux Linux dispone de una serie de macros que facilitan el acceso a determinados campos de algunas estructuras. Se suele sugerir que se empleen, porque además, si en algún momento un campo de una estructura es renombrado o modificado, aquellas funciones que hagan uso de la macro seguirán funcionando correctamente sin modificación alguna. # i n c l u d e <l i n u x / f s. h> Listado 5.13: Macro bio data dir. # 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 parámetro corresponde a una escritura; en caso de una lectura devuelve false. Y bio iovec idx devuelve la 86

99 5.7 Utilización de macros de Linux estructura bio vec, del BIO pasado como parámetro, que va a utilizarse en la transferencia de datos. La macro bio sectors devuelve el número de sectores que intervendrán en la transferencia. # i n c l u d e <l i n u x / b i o. h> Listado 5.14: Macros bio iovec dix y bio sectors. # 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) Además de este tipo de macros, hay otro tipo cuya misión es optimizar el código objeto generado. La macro likely se usa en aquellos chequeos o comprobaciones cuya respuesta se sabe que va a ser cierta, o true, en la mayoría de los casos. Por contra, la macro unlikely es 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 código para un bloque condicional o comprobación, se hace que salte o no el flujo de ejecución dependiendo del resultado de la comprobación. Los saltos perjudican el rendimiento, ya que suele ser necesario vaciar el pipeline 8 e introducir en el mismo las instrucciones correspondientes a la zona de salto. Cuando el compilador está generando código objeto y encuentra estas macros decide emitir instrucciones que hagan variar el flujo de ejecución, es decir, saltar, en el caso menos 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) ; } 8 Un pipeline es un conjunto de etapas conectadas entre sí de forma que la salida de una es la entrada de otra. Las instrucciones atraviesan estas etapas de una en una para poder realizar su labor. Al estar segmentado se pueden paralelizar las etapas de forma que todas trabajen a la vez aunque cada una tenga una función distinta y así mejorar el rendimiento. 87

100 CARACTERÍSTICAS OPCIONALES En el ejemplo 5.16, se ha indicado que es poco probable que falle la creación de un nuevo BIO por medio de bio alloc, así que el código objeto generado, en la zona correspondiente a este ejemplo, tendrá una instrucción de salto para el caso de que falle la comprobación. Como es poco probable que esto suceda, el salto se tomará muy pocas veces, penalizando menos que si fuera al revés: que se saltara si la creación de un nuevo BIO fuese exitosa. Obviamente, estas dos macros sólo deben utilizarse cuando se sepa con bastante seguridad cuál va a ser el desarrollo normal de los chequeos. En caso contrario, pueden penalizar más que ayudar Integración con el sistema de compilación del núcleo Linux Linux se apoya en la herramienta Make para crear imágenes y módulos a partir de los ficheros fuente. Mediante un menú se puede seleccionar el hardware para el cual se desea que Linux incluya soporte. Además, se pueden configurar multitud de opciones que van desde el soporte de carga y descarga de módulos hasta los sistemas de ficheros a los que se 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 información que se mostrará al usuario cuando, mediante el menú, personalice su compilación de Linux (ver listado 5.17). Makefile: contiene información para el sistema de compilación acerca de los objetivos o ficheros 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 compilación, y opcional integración, del código del controlador del dispositivo virtual. Todo el desarrollo de la solución se ha confinado dentro de un parche que puede ser aplicado sobre cualquier revisión de Linux , facilitando así su distribución. El menú de compilación de Linux, una vez aplicado el parche, quedaría modificado para permitir la compilación de la solución. La aplicación de control del usuario se distribuye como un fichero único que deberá ser compilado de forma tradicional, independientemente del sistema de compilación del núcleo 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 RBD t r i s t a t e RollBack 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

101 5.8 Integración con el sistema de compilación del núcleo Linux Listado 5.18: Fichero Makefile del controlador. # # M a k e f i l e f o r t h e RollBack d e v i c e # obj $ ( CONFIG BLK DEV RBD ) += rbd. o rbd o b j s := d e v i c e. o map. o 89

102

103 Capítulo 6 CONCLUSIONES Y FUTURAS LÍNEAS 6.1. Conclusiones Brevemente, los objetivos del proyecto eran los siguientes: 1. Proponer y desarrollar una solución que permitiese modificar el contenido de un sistema de ficheros, sin que estas modificaciones fuesen permanentes: se han propuesto varias alternativas, discutiéndose sus beneficios e inconvenientes, y se ha escogido aquella que ha parecido más sensata y correcta. Durante la explicación del desarrollo e implementación de la solución, se ha podido observar que, en ningún momento, una vez esté en marcha la solución, se modificará el dispositivo de lecturas y que, en conjunción con el dispositivo de escrituras, el dispositivo virtual ofrecerá una imagen al usuario que será combinación de los otros dos dispositivos. 2. La solución debía funcionar en Linux: la solución funciona exclusivamente en Linux por su dependencia del módulo desarrollado. 3. Debía ser lo más genérica posible: la solución es genérica en el sentido de que no está atada a un sistema de ficheros, sino que funciona con aquellos que delimiten el espacio dentro del soporte con bloques del mismo tamaño. 4. Las modificaciones no debían mantenerse en memoria, sino en otro soporte, por ejemplo particiones o ficheros: todas las modificaciones se vuelcan al dispositivo de escrituras elegido, manteniendo en memoria las estructuras necesarias para operar y aquellos datos que mantenga en caché el propio Linux. 5. El usuario no debería notar diferencia alguna entre un sistema con la solución en marcha y otro sin ella, salvo en que las modificaciones realizadas no son permanentes: para el usuario, la única diferencia podría ser una ligera penalización en el rendimiento por la manipulación adicional a la que son sometidas las peticiones BIO. 91

104 CONCLUSIONES Y FUTURAS LÍNEAS 6. Los cambios serían deshechos automáticamente al apagar el equipo. Opcionalmente, una aplicación de apoyo podría realizar esta misma tarea sin tener que reiniciar: puesto que las estructuras de control están en memoria, una vez se apague el equipo o se fuerce la reinicialización de las estructuras por medio de la aplicación de control, las escrituras serán inaccesibles para el usuario. Seguirán estando en el dispositivo de escrituras, pero no se podrán recuperar en el sentido de que no hay información que permita relacionar los bloques ahí almacenados con aquellos a los que debieran sustituir en el dispositivo de lecturas. 7. Opcionalmente, el sistema de ficheros raíz podría funcionar bajo el control de la solución, de forma que los cambios en él efectuados sean temporales: no hay nada en el desarrollo de la solución que impida que el sistema raíz sea montado encima del dispositivo virtual. Esta configuración fue probada y lo único necesario es, al igual que con los sistemas RAID, poder activar el dispositivo antes de que llegue a montarse el sistema raíz. Esto se consigue por medio de: a) Un sistema raíz mínimo, que será cargado exclusivamente en memoria, y desde el que se operará para poder crear el dispositivo virtual, antes de montar el sistema raíz, normalmente embebido dentro de la imagen del núcleo. b) La aplicación rbdctl. Es necesario que esta y todas las aplicaciones que se utilicen durante el arranque estén compiladas estáticamente, para no depender de biblioteca alguna. c) Un intérprete de comandos junto con un script encargado de invocar la aplicación rbdctl y crear el dispositivo rbd. Posteriormente, el script deberá pasar el control al proceso init. Los objetivos obligatorios descritos hasta ahora han sido alcanzados plenamente. Se ha añadido otro objetivo opcional: la posibilidad de evitar perder los cambios y mantenerlos. 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 través del dispositivo virtual. Además, el que los dispositivos de lecturas y escrituras sean eso, dispositivos de bloques, permite utilizar un amplio abanico de posibilidades: particiones en discos IDE, SA- TA y USB, discos virtuales en memoria, ficheros mostrados como dispositivos por medio del dispositivo loop 1, etc. Si se dispone de suficiente memoria, es preferible crear un disco virtual en memoria, de forma que las escrituras se redirijan a ese hardware, mucho más veloz que un disco. Mediante la herramienta rbdctl se puede conocer el estado de cada dispositivo virtual, sobre todo información importante, como el nivel de ocupación de los bloques libres del dispositivo de escrituras y el consumo actual en memoria del mapa. Finalmente, durante la fase de testeo se realizaron pruebas con varios tamaños de bloque (1024, 2048 y 4096 bytes) y con distintos sistemas de ficheros (Ext2, Ext3, ReiserFS y JFS), y la solución funcionó perfectamente. 1 device 92

105 6.2 Futuras líneas 6.2. Futuras líneas La solución, aunque cumple los objetivos y es completamente funcional, puede ser mejorada añadiendo alguna de las siguientes características: Interfaz gráfica: a pesar de la simplicidad que ofrece la herramienta rbdctl desde línea de comandos, una interfaz gráfica siempre es más cómoda de usar. Persistencia: una vez se reinicia el equipo, los datos del dispositivo de escrituras dejan de estar disponibles. Siguen ahí, pero no se tiene el mapa que relaciona su contenido con los bloques del dispositivo de lecturas. Almacenar de alguna forma el mapa, quizá en el propio soporte de escrituras, sería una posible solución para seguir disponiendo de los datos modificados, aunque en el futuro estos sean rechazados. Puntos de restauración: un paso más con respecto a la persistencia sería el soporte para varias puntos de restauración. Se podría congelar el estado actual del dispositivo de escrituras e iniciar otro mapa desde cero, como si se comenzase a utilizar el dispositivo virtual. Así, sería posible realizar modificaciones sobre cambios ya realizados antes del punto de restauración y volver a cualquiera de los puntos guardados, hasta el original. Soporte de más sistemas de ficheros: la solución, como ya se ha comentado, ha sido probada satisfactoriamente con los sistemas de ficheros Ext2, Ext3, ReiserFS y JFS, pero todavía quedan más sistemas como XFS o Reiser4. Por tanto, estos sistemas deberían probarse y, si fuera necesario, deberá modificarse el controlador para darles soporte. Función identidad como mapa: si el soporte de escrituras tiene un tamaño igual o mayor que el de lecturas, no haría falta mapa alguno. Se podría utilizar una función identidad para relacionar los dos soportes, de forma que el bloque X del dispositivo de lecturas se corresponde con el mismo bloque, pero en el dispositivo de escrituras. Compartición del soporte de escrituras: cada dispositivo virtual relaciona un dispositivo de lecturas con uno de escrituras. Si se compartiera el espacio del dispositivo de escrituras entre varias instancias del dispositivo virtual, podría ahorrarse espacio, de forma que no hubiera que utilizar exclusivamente un soporte de escrituras distinto para cada instancia del dispositivo virtual. Es más, quizá podrían combinarse varios soportes de escrituras como un único soporte, similar a un RAID 0, y utilizar ese espacio de forma común entre las distintas instancias del dispositivo virtual a la hora de escribir. Hibernar y suspender: el soporte para la transición a los estados de suspensión e hibernación, no se ha probado por considerar que estas características están todavía en desarrollo en Linux. Una vez se estabilicen estas dos características debería estudiarse si el controlador tiene problemas a la hora de transitar a esos estados y, en caso afirmativo, solucionarlo. 93

106 CONCLUSIONES Y FUTURAS LÍNEAS 6.3. Estadísticas Un 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 completó a finales de junio de La implementación de la solución tuvo lugar desde febrero del 2007 hasta principios de abril del La memoria del proyecto se redactó durante el período que va desde febrero de 2008 hasta finales de junio del mismo año, partiendo de anotaciones realizadas durante la fase de implementación. La solución se compone de 1080 SLOC 2 C para el controlador y 399 para la herramienta de control rbdctl. A pesar de no ser muchas líneas, el mayor problema en el desarrollo estuvo en el particular y restrictivo entorno de ejecución que supone un núcleo Linux y la dispersa y escasa documentación existente. Figura 6.1: Gráfica correspondiente a la evolución de las líneas de código de la solución. 2 Source Lines Of Code es una métrica software usada para medir el tamaño de un desarrollo software mediante la cuenta del número de líneas en los fuentes del programa, despreciando las que estén en blanco o sean comentarios. 94