Un sistema de archivos con diario es un sistema de archivos que realiza un seguimiento de los cambios que aún no se han comprometido en la parte principal del sistema de archivos registrando el objetivo de dichos cambios en una estructura de datos conocida como " diario ", que suele ser un registro circular . En caso de una falla del sistema o un corte de energía, dichos sistemas de archivos pueden volver a estar en línea más rápidamente con una menor probabilidad de corromperse . [1] [2]
Dependiendo de la implementación real, es posible que un sistema de archivos de diario solo realice un seguimiento de los metadatos almacenados , lo que resulta en un mejor rendimiento a expensas de una mayor posibilidad de corrupción de datos. Alternativamente, un sistema de archivos de diario puede rastrear tanto los datos almacenados como los metadatos relacionados, mientras que algunas implementaciones permiten un comportamiento seleccionable a este respecto. [3]
En 1990, IBM introdujo JFS en AIX 3.1 como uno de los primeros sistemas de archivos comerciales UNIX que implementó el registro en diario. [4] Al año siguiente, la idea se popularizó en un artículo ampliamente citado sobre sistemas de archivos estructurados en registros. [5] Esto se implementó posteriormente en el sistema de archivos NTFS de Windows NT de Microsoft en 1993, en el sistema de archivos HFS Plus de Apple en 1998 y en el sistema de archivos ext3 de Linux en 2001. [6]
La actualización de los sistemas de archivos para reflejar los cambios en archivos y directorios generalmente requiere muchas operaciones de escritura separadas. Esto hace posible que una interrupción (como un corte de energía o una falla del sistema ) entre escrituras deje las estructuras de datos en un estado intermedio no válido. [1]
Por ejemplo, eliminar un archivo en un sistema de archivos Unix implica tres pasos: [7]
Si se produce un bloqueo después del paso 1 y antes del paso 2, habrá un inodo huérfano y, por tanto, una fuga de almacenamiento ; Si se produce un bloqueo entre los pasos 2 y 3, los bloques utilizados anteriormente por el archivo no se pueden utilizar para archivos nuevos, lo que disminuye efectivamente la capacidad de almacenamiento del sistema de archivos. Reorganizar los pasos tampoco ayuda. Si el paso 3 precedió al paso 1, una falla entre ellos podría permitir que los bloques del archivo se reutilicen para un archivo nuevo, lo que significa que el archivo parcialmente eliminado contendría parte del contenido de otro archivo, y las modificaciones a cualquiera de los archivos se mostrarían en ambos. Por otro lado, si el paso 2 precediera al paso 1, una falla entre ellos haría que el archivo fuera inaccesible, a pesar de que parezca existir.
Detectar y recuperarse de tales inconsistencias normalmente requiere un recorrido completo de sus estructuras de datos, por ejemplo mediante una herramienta como fsck (el verificador del sistema de archivos). [2] Por lo general, esto debe hacerse antes de que el sistema de archivos se monte a continuación para acceso de lectura y escritura. Si el sistema de archivos es grande y hay relativamente poco ancho de banda de E/S, esto puede llevar mucho tiempo y provocar tiempos de inactividad más prolongados si bloquea el resto del sistema para que no vuelva a estar en línea.
Para evitar esto, un sistema de archivos con diario asigna un área especial (el diario) en la que registra los cambios que realizará con anticipación. Después de una falla, la recuperación simplemente implica leer el diario del sistema de archivos y reproducir los cambios de este diario hasta que el sistema de archivos vuelva a ser consistente. Por lo tanto, se dice que los cambios son atómicos (no divisibles) en el sentido de que tienen éxito (tuvieron éxito originalmente o se repiten por completo durante la recuperación), o no se repiten en absoluto (se omiten porque aún no se habían escrito completamente en el diario antes de la ocurrió el accidente).
Algunos sistemas de archivos permiten que el diario crezca, se reduzca y se reasigne como un archivo normal, mientras que otros colocan el diario en un área contigua o en un archivo oculto que garantiza que no se moverá ni cambiará de tamaño mientras el sistema de archivos esté montado. Algunos sistemas de archivos también pueden permitir registros externos en un dispositivo separado, como una unidad de estado sólido o una RAM no volátil respaldada por batería. Los cambios en el diario pueden registrarse para lograr una redundancia adicional, o el diario puede distribuirse en varios volúmenes físicos para proteger contra fallas del dispositivo.
El formato interno de la revista debe proteger contra fallas mientras se escribe en la revista. Muchas implementaciones de diarios (como la capa JBD2 en ext4 ) ponen entre paréntesis cada cambio registrado con una suma de verificación, en el entendido de que una falla dejaría un cambio parcialmente escrito con una suma de verificación faltante (o no coincidente) que puede simplemente ignorarse al reproducir el diario en próximo remontaje.
Un diario físico registra una copia anticipada de cada bloque que luego se escribirá en el sistema de archivos principal. Si se produce un bloqueo cuando se escribe en el sistema de archivos principal, la escritura puede simplemente reproducirse hasta completarse la próxima vez que se monte el sistema de archivos. Si se produce un bloqueo cuando la escritura se registra en el diario, a la escritura parcial le faltará una suma de comprobación o no coincidirá y podrá ignorarse en el siguiente montaje.
Los diarios físicos imponen una penalización significativa en el rendimiento porque cada bloque modificado debe enviarse dos veces al almacenamiento, pero pueden ser aceptables cuando se requiere una protección absoluta contra fallas. [8]
Un diario lógico almacena solo cambios en los metadatos del archivo en el diario y cambia la tolerancia a fallos por un rendimiento de escritura sustancialmente mejor. [9] Un sistema de archivos con un diario lógico aún se recupera rápidamente después de una falla, pero puede permitir que los datos de archivos no registrados y los metadatos registrados no estén sincronizados entre sí, causando corrupción de datos.
Por ejemplo, agregar un archivo puede implicar tres escrituras separadas en:
En una revista de sólo metadatos, el paso 3 no se registraría. Si no se realizó el paso 3, pero los pasos 1 y 2 se repiten durante la recuperación, se agregará basura al archivo.
La caché de escritura en la mayoría de los sistemas operativos clasifica sus escrituras (usando el algoritmo elevador o algún esquema similar) para maximizar el rendimiento. Para evitar un riesgo de escritura desordenada con un diario de solo metadatos, las escrituras de datos de archivos deben ordenarse para que se almacenen antes que sus metadatos asociados. Esto puede resultar complicado de implementar porque requiere coordinación dentro del núcleo del sistema operativo entre el controlador del sistema de archivos y la caché de escritura. También puede ocurrir un riesgo de escritura desordenada si un dispositivo no puede escribir bloques inmediatamente en su almacenamiento subyacente, es decir, no puede vaciar su caché de escritura en el disco debido a que la escritura diferida está habilitada.
Para complicar las cosas, muchos dispositivos de almacenamiento masivo tienen sus propios cachés de escritura, en los que pueden reordenar agresivamente las escrituras para mejorar el rendimiento. (Esto es particularmente común en los discos duros magnéticos, que tienen grandes latencias de búsqueda que pueden minimizarse con la clasificación por elevador.) Algunos sistemas de archivos de registro por diario suponen de manera conservadora que dicha reordenación de escritura siempre ocurre y sacrifican el rendimiento en aras de la corrección al obligar al dispositivo a vaciar su contenido. caché en ciertos puntos del diario (llamados barreras en ext3 y ext4 ). [10]
Algunas implementaciones de UFS evitan el registro en diario y en su lugar implementan actualizaciones suaves : ordenan sus escrituras de tal manera que el sistema de archivos en el disco nunca sea inconsistente, o que la única inconsistencia que se puede crear en caso de una falla sea una fuga de almacenamiento. Para recuperarse de estas filtraciones, el mapa de espacio libre se concilia con un recorrido completo del sistema de archivos en el siguiente montaje. Esta recolección de basura generalmente se realiza en segundo plano. [11]
En los sistemas de archivos estructurados en registros , la penalización de escritura dos veces no se aplica porque el diario en sí es el sistema de archivos: ocupa todo el dispositivo de almacenamiento y está estructurado para que pueda recorrerse como lo haría un sistema de archivos normal.
Los sistemas de archivos completos de copia en escritura (como ZFS y Btrfs ) evitan cambios in situ en los datos del archivo al escribir los datos en bloques recién asignados, seguidos de metadatos actualizados que apuntarían a los nuevos datos y repudiarían los antiguos, seguidos de mediante metadatos que apuntan a eso, y así sucesivamente hasta el superbloque, o la raíz de la jerarquía del sistema de archivos. Tiene las mismas propiedades de preservación de la corrección que un diario, sin la sobrecarga de escribir dos veces.