Sistemas operativos modernos

Hay varias optimizaciones y mejoras posibles que pueden aplicarse a este esquema. Por principio de cuentas, es factible, pero costoso, comparar todos los bloques por pares después de una falla. Algo mucho mejor es mantenerse al tanto de cuál bloque se está escribiendo du­ rante una escritura estable, de modo que sólo sea necesario examinar un bloque durante la re­ cuperación. Algunas computadoras cuentan con una pequeña cantidad de RAM no volátil que es una memoria CMOS especial alimentada por una batería de litio. Esas baterías duran años, tal vez toda la vida de la computadora. A diferencia de la memoria principal, que se pierde después de una falla, la RAM no volátil no se pierde. Por lo general, ahí se guarda la hora del día (y se in­ crementa con un circuito especial); es por esto que las computadoras siguen manteniendo la ho­ ra correcta aun después de desconectarse. Supongamos que se cuenta con unos cuantos bytes de RAM no volátil que el sistema ope­ rativo puede usar para sus fmes. La escritura estable puede colocar ahí el número del bloque que está a punto de actualizar, antes de iniciar la escritura. Una vez terminada con éxito la es­ critura estable, el número de bloque en la RAM no volátil se sobreescribe con un número de bloque no válido, digamos -1. En estas condiciones, después de una caída el programa de re­ cuperación podrá consultar la RAM no volátil para ver si se estaba efectuando una escritura es­ table durante la falla y, en tal caso, cuál bloque se estaba escribiendo cuando ocurrió. Entonces podrá verificarse la corrección y congruencia de las dos copias del bloque. Si no se cuenta con RAM no voláfil, podrá simularse como sigue. Al principio de una es­ critura estable, un bloque de disco fijo en la unidad 1 se sobreescribe con el número del bloque que se escribirá de manera estable. Luego se lee ese bloque para verificarlo. Una vez que está correcto, se escribe y verifica el bloque correspondiente en la unidad 2. Al terminar la escritura estable en forma correcta, ambos bloques se sobreescriben con un número de bloque no válido y se verifican. Después de una falla, también será fácil determinar con este esquema si se esta­ ba efectuando o no una escritura estable durante la caída. Claro que esta técnica requiere ocho operaciones de disco adicionales para escribir un bloque estable, por lo que sólo se le deberá ufi- lizar cuando en verdad sea indispensable. Vale la pena destacar un úlfimo punto. Supusimos que sólo uno de los bloques de un par de bloques dado puede arruinarse de manera espontánea en un mismo día. Si pasan suficientes días, también podría arruinarse el otro bloque. Por tanto, deberá efectuarse una exploración completa de ambos discos una vez al día, reparando los daños que se detecten. Así, cada ma­ ñana ambos discos siempre serán idénticos. Incluso si ambos bloques de un par se arruinan dentro de un periodo de unos cuantos días, todos los errores se repararán en forma correcta. 5.5 RELOJES Los relojes (también llamados temporizadores) son indispensables para el funcionamiento de cualquier sistema multiprogramado, por diversas razones. Entre otras cosas, mantienen la hora del día y evitan que un proceso monopolice la CPU. El software de reloj puede adoptar la forma de un controlador de dispositivo, aunque un reloj no es un dispositivo de bloques, como un disco, ni un dispositivo de caracteres, como un ratón. Nuestro estudio de los relojes seguirá el mismo patrón que en la sección anterior: primero examinaremos el hardware de reloj y luego el software.