Un sistema de archivos con registro es un sistema de archivos que lleva un registro de los cambios que aún no se han confirmado 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 que se produzca una caída del sistema o un corte de energía, dichos sistemas de archivos pueden volver a estar en línea más rápidamente y con una menor probabilidad de que se corrompan . [1] [2]
Dependiendo de la implementación actual, un sistema de archivos con registro en diario puede solo realizar 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 con registro en diario puede realizar un seguimiento tanto de los datos almacenados como de 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 de 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 los archivos y directorios suele requerir muchas operaciones de escritura independientes. Esto hace posible que una interrupción (como un corte de energía o un fallo 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 fallo después del paso 1 y antes del paso 2, habrá un inodo huérfano y, por lo tanto, una fuga de almacenamiento ; si se produce un fallo entre los pasos 2 y 3, los bloques utilizados anteriormente por el archivo no se pueden utilizar para nuevos archivos, lo que reduce efectivamente la capacidad de almacenamiento del sistema de archivos. Reorganizar los pasos tampoco ayuda. Si el paso 3 precedió al paso 1, un fallo entre ellos podría permitir que los bloques del archivo se reutilizaran para un nuevo archivo, lo que significa que el archivo parcialmente eliminado contendría parte del contenido de otro archivo y las modificaciones a cualquiera de los archivos aparecerían en ambos. Por otro lado, si el paso 2 precedió al paso 1, un fallo entre ellos haría que el archivo fuera inaccesible, a pesar de parecer existir.
Para detectar y recuperarse de estas inconsistencias, normalmente es necesario recorrer por completo las estructuras de datos, por ejemplo, con una herramienta como fsck (el verificador del sistema de archivos). [2] Esto se debe hacer normalmente antes de montar el sistema de archivos para el 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 impide que el resto del sistema vuelva a estar en línea.
Para evitarlo, un sistema de archivos con registro asigna un área especial (el registro) en la que registra los cambios que realizará con antelación. Después de una falla, la recuperación simplemente implica leer el registro del sistema de archivos y reproducir los cambios desde este registro 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 o bien se realizan correctamente (se realizaron correctamente originalmente o se reproducen completamente durante la recuperación) o bien no se reproducen en absoluto (se omiten porque aún no se habían escrito completamente en el registro antes de que ocurriera la falla).
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 se 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 diarios externos en un dispositivo independiente, 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 obtener redundancia adicional, o el diario puede distribuirse en varios volúmenes físicos para protegerse contra fallas del dispositivo.
El formato interno del diario debe protegerse contra fallas mientras se escribe en el diario. Muchas implementaciones de diario (como la capa JBD2 en ext4 ) incluyen cada cambio registrado con una suma de comprobación, entendiendo que una falla dejaría un cambio escrito parcialmente con una suma de comprobación faltante (o no coincidente) que simplemente se puede ignorar al reproducir el diario en el próximo montaje.
Un diario físico registra una copia anticipada de cada bloque que luego se escribirá en el sistema de archivos principal. Si se produce una falla cuando se está escribiendo en el sistema de archivos principal, la escritura se puede reproducir hasta completarse la próxima vez que se monte el sistema de archivos. Si se produce una falla cuando se está registrando la escritura en el diario, la escritura parcial tendrá una suma de comprobación faltante o no coincidente y se puede ignorar en el próximo montaje.
Los diarios físicos imponen una importante penalización de rendimiento porque cada bloque modificado debe ser enviado dos veces al almacenamiento, pero pueden ser aceptables cuando se requiere protección absoluta contra fallas. [8]
Un diario lógico almacena solo los cambios en los metadatos de los archivos en el diario y sacrifica la tolerancia a fallas 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 se desincronizan entre sí, lo que causa corrupción de datos.
Por ejemplo, agregar algo a un archivo puede implicar tres escrituras independientes en:
En un diario que solo contenga metadatos, no se registraría el paso 3. Si no se realizó el paso 3, pero se repiten los pasos 1 y 2 durante la recuperación, se agregará basura al archivo.
La caché de escritura en la mayoría de los sistemas operativos ordena sus escrituras (usando el algoritmo del elevador o algún esquema similar) para maximizar el rendimiento. Para evitar un riesgo de escritura fuera de orden con un diario de solo metadatos, las escrituras de datos de archivo deben ordenarse de modo que se asignen al almacenamiento antes que sus metadatos asociados. Esto puede ser 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. Un riesgo de escritura fuera de orden también puede ocurrir 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 un mejor rendimiento. (Esto es particularmente común en los discos duros magnéticos, que tienen grandes latencias de búsqueda que se pueden minimizar con la ordenación por elevador). Algunos sistemas de archivos con registro en diario asumen de manera conservadora que dicha reordenación de escritura siempre tiene lugar y sacrifican el rendimiento por la corrección al obligar al dispositivo a vaciar su caché en ciertos puntos del registro (llamados barreras en ext3 y ext4 ). [10]
Algunas implementaciones de UFS evitan el registro 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 pueda crear en caso de una falla sea una pérdida de almacenamiento. Para recuperarse de estas pérdidas, 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 por escritura doble no se aplica porque el diario en sí es el sistema de archivos: ocupa todo el dispositivo de almacenamiento y está estructurado de modo que se puede recorrer como lo haría un sistema de archivos normal.
Los sistemas de archivos con copia en escritura completa (como ZFS y Btrfs ) evitan los cambios en el lugar de los datos de los archivos al escribir los datos en bloques recién asignados, seguidos de metadatos actualizados que apuntarían a los nuevos datos y rechazarían los antiguos, seguidos de metadatos que apuntarían a estos, y así sucesivamente hasta el superbloque o la raíz de la jerarquía del sistema de archivos. Esto tiene las mismas propiedades de conservación de la corrección que un diario, sin la sobrecarga de la doble escritura.