En Minix 3 el driver del disco duro at wini es secuencial. No es concurrente. No toma (recibe) encargo de otras operaciones hasta que ha acabado de atender la que está procesando. Exponer factores a favor y en contra, ventajas e inconvenientes, de esta decisión. 1. Si el driver es secuencial el código del driver es más sencillo, más fácil de escribir y mantener. 2. Si tenemos un disco, con el driver concurrente no se gana paralelismo en el hardware. Si tenemos varios discos (suponemos que la electrónica permite su uso simultáneo) el driver concurrente permite obtener mayor rendimiento. 3. El tiempo de posicionamiento de la cabeza de lectura/escritura de los discos es significativo. Con un driver concurrente se puede planificar el servicio a los distintos cilindros (algoritmos ascensor o S-scan) y disminuir el tiempo medio de servicio. 4. Si FS es el único cliente del driver de disco y espera a que acabe una petición antes de hacer la siguiente, no se consigue nada con paralelismo en el driver de disco. 5. La comunicación entre FS y driver de disco incluye vector-io (petición de entrada salida de multiples bloques). El FS puede planificar el acceso (a cilindros) de un disco. 6. Si FS (modificado?) puede hacer multiples encargos/peticiones (no vector-io) al driver de disco, éste deberá poder limitar el número de encargos/peticiones pendientes cuando se alcance un valor máximo. 7. Si FS limita el número de encargos/peticiones, el driver de disco en versión concurrente debe hacer receive por timout, y receive por terminación de la operación de entrada/salida. Por otra parte (punto 6) en ocasiones debe ignorar los mensajes de FS. Esto implica recibir mensajes de dos origenes e ignorar los mensajes de un tercer origen. Minix 3 tiene recepción de cualquiera (any) o de una fuente. Necesitariamos ’receive selectivo’ de varias origenes. No aparece en la documentación de Minix 3. Implementarlo supone un trabajo adicional. 8. (Como alternativa al punto 7) Podemos enviar un mensaje del tipo ’driver-ocupado,-vuelva-llamar-en-5-min.’ al FS. 9. (Como alternativa al punto 6) O se autolimita FS a un número máximo de encargos/peticiones. 10. Un acceso con localidad (no aleatorio) aprovecha menos de la planificación de acceso a cilindros. 1 11. En caso de utilizar un simulador como Qemu, no está claro que se aprecie una ventaja en la planificación de la cabeza de lectura/escritura. Si se utiliza una imagen de disco, los cilindros en la simulación no tienen por qué coincidir con cilindros reales. Y la diferencia puede ser mayor si la imagen de disco asigna bloques según demanda. 12. La ventaja de utilizar un driver concurrente depende del perfil de uso que se de al sistema. 13. Una modificación en el driver genérico de bloques afecta a todos los drivers de bloques, a menos que separemos la compilación del dirver de disco duro. 14. La planificación de las lecturas y escrituras por el driver de disco duro interfiere con la planificación de procesos del kernel. No está claro que el resultado esté de acuerdo con los objetivos de un administrador que en principio sólo interviene en la politica del kernel (nice, ..). Esto afecta tanto al driver secuencial como al concurrente, pero parece más sencillo coordinar al FS con el kernel para gestionar prioridades que introducir gestión de las prioridades en el driver de disco duro. 15. La ventaja del paralelismo (driver concurrente) se aprecia si se acumulan las peticiones de uso del disco. Esto parece mas probable en servidores que en ordenadores de uso personal. 16. La mayor disponibilidad de memoria RAM resta protagonismo al disco duro. Casi toda la información necesaria se encuentra en bufers. 17. Un mecanismo muy usado para dar servicio concurrente son los hilos (hebras/threads) de las que Minix 3 carece (de momento). En resumen. Un driver concurrente (parece que) es una mejora. Pero esa mejora tiene un coste considerable. Y conviene hacerlo porque no perjudica, y su implementación puede beneficiar a muchos usuarios. Suponemos que Minix 3 vive largos años y que los discos duros no desaparecen en un par de años. Más importante es comprobar cómo a veces un cambio aparentamente sencillo tiene múltiples implicaciones. Este tema se debatió en tres grupos de Sistemas Operativos II, curso 2007/08. En cada grupo afloró más de una docena de consideraciones, y se puso como objetivo ser capaz de presentar 6 elementos de argumentación. 2