4 3B Theoretical position
4.2. Contingency thinking
• El kernel ordena operaciones de escritura en disco para minimizar en lo posible la corrupción del sistema de archivos en caso de caída del sistema.
• Nada más crear el sistema de archivos, debemos revisarlo para verificar la consistencia y asegurar que todos sus bloques son accesibles. Esto se consigue mediante el programa fsck . fsck revisa y repara de forma interactiva las posibles inconsistencias que encuentra en los sistemas de archivos de UNIX. Si el sistema no presenta inconsistencias, el programa fsck informa sobre el número de archivos, número de bloques utilizados y número de bloques libres de que dispone el sistema. Si el sistema es inconsistente, fsck proporciona mecanismos para corregirlo.
• Las inconsistencias que revisa fsck son las siguientes:
– Bloques reclamados por más de un inodo (inode) o la lista de bloques libres.
– Bloques reclamados por un inodo (inode) o la lista de bloques libres, pero que están fuera del rango del sistema.
– Contadores de enlaces incorrectos. – Revisión de tamaños:
+ Número de bloques demasiado grande. + Tamaños de directorios inadecuado. – Formato inadecuado para los inodos (inodes).
– Bloques no registrados por nadie (inodos (inodes), lista de bloques libres, etc.). – Revisión en directorios:
+ Archivos que apuntan a inodos (inodes) no asignados. + Números de inodos (inodes) fuera de rango.
– Revisión en el superbloque ⇒ más bloques para inodos (inodes) de los que hay en el sistema de archivos.
– Formato incorrecto de la lista de bloques libres.
– Total de bloques libres o contados de inodos (inodes) libres incorrecto.
• Si fsck encuentra un archivo o directorio cuyo directorio padre no puede determinarse, colocará al archivo huérfano en el directorio lost + found perteneciente al sistema que se está revisando. Puesto que el nombre del archivo registra en su directorio home y éste es desconocido, a la hora de guardarlo en lost+found no podemos hacerlo con su verdadero nombre, por lo que se nombrará con su número de inodo (inode).
• La utilidad fsck no sólo se utiliza para revisar el sistema de archivos recién creado. Su misión principal es revisar sistemas estropeados por alguna causa accidental como una parada incontrolada del sistema. Como sabemos, el sistema mantiene copias en memoria tanto del superbloque como de la lista de inodos. Además, el acceso a disco se realiza a través del buffer caché. Esto crea inconsistencias entre el disco y la memoria, inconsistencias que se corrigen periódicamente con al intervención de los demonios syncer y update, que se encargan de realizar las llamadas a sync para sincronizar el disco con la memoria. Si por cualquier circunstancia el sistema deja de funcionar antes de que se produzca una sincronización, la próxima vez que se intente ese sistema de archivos, será necesario repararlo en la medida de lo posible con la ayuda de fsck .
• Ejemplo: Eliminar un archivo.
– Borra el nombre de archivo del directorio padre y escribe de forma síncrona el directorio al disco, antes de liberar los bloques de datos del archivo y su inodo (inode). En el caso de que el sistema cayera antes de destruir el contenido del archivo, los daños serían mínimos.
– Si la escritura del directorio no fuera síncrona, habría la posibilidad de que existiera una entrada en un directorio que apuntaría a un inodo (inode) libre (o reasignado) después de la caída del sistema de archivos.
• Ejemplo: Eliminar un archivo.
– Al eliminar el contenido de un archivo y su inodo (inode), es posible liberar primero los bloques de datos o liberar y escribir primero el inodo (inode).
+ Caso1: Liberar primero los bloques de datos y caída del sistema.
* Reinicio ⇒ inodo (inode) referencia a bloques que no tienen datos del archivo. * El kernel ve al archivo aparentemente correcto.
* El usuario notaría el problema al acceder al archivo.
* Puede que los bloques de datos se asignasen a otro(s) archivo(s) ⇒ fsck ⇒ gran esfuerzo para limpiar el sistema de archivos.
+ Caso 2: Escribir primero el inodo (inode) y después cae el sistema. * El usuario no notará nada anormal en el sistema de archivos.
* Los bloques de datos asignados al archivo no son accesibles, pero los usuarios no tendrán conciencia del problema.
* fsck busca los bloques de datos que no pertenecen a ningún archivo.
• En lo que respecta al mantenimiento del sistema de archivos, debemos recordar que en el funcionamiento normal del sistema ⇒ el kernel mantiene la consistencia del sistema de archivos. • Caída del sistema ⇒ puede dejar al sistema de archivos en estado inconsistente ⇒ la mayor parte
de los datos del sistema de archivos son válidos.
• fsck chequea el sistema de archivos y lo repara, en caso de encontrar inconsistencias.
• Ejemplo: Un bloque de disco pertenece a más de un inodo (inode) o a lista de libres y a un inodo (inode).
– Al crear un sistema de archivos ⇒ todos los bloques de disco están en la lista de libres. – Asignar un bloque de disco ⇒ el kernel lo elimina de lista de libres y lo asigna a un inodo
(inode).
– No se le puede reasignar a otro inodo (inode) hasta que quede libre otra vez. – Puede suceder que el kernel:
+ Libera un bloque de disco de un archivo.
+ Coloca el nº de bloque en lista de libres del superbloque en memoria. + Asigna el bloque de disco a un archivo nuevo.
+ Si kernel escribe el inodo (inode) y bloque del archivo nuevo al disco y el sistema cae antes de actualizar el inodo (inode) del archivo antiguo, ambos inodos (inodes) apuntarán al mismo número de bloque de disco.
– O puede suceder que:
+ El kernel escribe el superbloque y su lista de libres y cae antes de escribir el inodo (inode) antiguo ⇒ el bloque de disco aparecería en la lista de libres y en el antiguo inodo (inode).
• Ejemplo: Un nº de bloque no aparece en la lista de libres ni en algún inodo (inode).
– El sistema de archivos está en un estado inconsistente porque todo nº de bloque debe aparecer en algún sitio, y puede suceder que:
+ Se libera un bloque de un archivo
+ Se coloca su número de bloque en el superbloque. + Se escribe el inodo (inode) del archivo en el disco.
+ Cae el sistema antes de actualizar la lista de libres del superbloque.
• Ejemplo: Un inodo (inode) con nº de enlaces diferente de 0 y no aparece en la estructura de directorios. Bajo esta situación, puede suceder que:
– El sistema cae después de crear un archivo pero antes de crear la entrada en su directorio padre.
• Ejemplo: Formato incorrecto del inodo (inode).
– Por ejemplo, el campo del tipo de archivo tiene un valor indefinido.
– Podría ocurrir que el administrador del sistema hubiera montado un sistema de archivos que no se había formateado apropiadamente.
• Ejemplo: El nº de inodo (inode) aparece en la entrada de directorio, pero el inodo (inode) está libre. – El sistema de archivos es inconsistente y puede suceder que:
+ El kernel crea un archivo y escribe la entrada en el directorio al disco pero no escribe el inodo (inode) en el disco antes de la caída del sistema.
+ Esta situación se evita ordenando las escrituras apropiadamente.
• Ejemplo: El nº de bloques o de inodos (inodes) libres del superbloque es diferente a los que existen en disco ⇒ sistema de archivos inconsistente ⇒ información del superbloque siempre debe coincidir con el estado del sistema de archivos.