Hispanopedia WikiUn sistema de archivos con registro de transacciones es un sistema de archivos que realiza un seguimiento 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 fallo del sistema o corte de energía, estos 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, un sistema de archivos con registro de transacciones puede limitarse a registrar los metadatos almacenados , lo que mejora el rendimiento a costa de una mayor probabilidad de corrupción de datos. Alternativamente, un sistema de archivos con registro de transacciones puede registrar tanto los datos almacenados como los metadatos relacionados, mientras que algunas implementaciones permiten seleccionar el comportamiento en este sentido. [ 3 ]
Historia
En 1990, IBM introdujo JFS en AIX 3.1 como uno de los primeros sistemas de archivos comerciales UNIX que implementó el registro de transacciones. [ 4 ] Al año siguiente, la idea se popularizó en un artículo ampliamente citado sobre sistemas de archivos estructurados en registros. [ 5 ] Posteriormente, esto se implementó 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 ]
Razón fundamental
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 caída 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 ]
- Eliminando su entrada de directorio.
- Liberando el inodo al conjunto de inodos libres.
- Devolviendo todos los bloques de disco al grupo de bloques de disco libres.
Si se produce un fallo después del paso 1 y antes del paso 2, quedará un inodo huérfano y, por lo tanto, una fuga de memoria ; si se produce un fallo entre los pasos 2 y 3, los bloques utilizados previamente por el archivo no podrán utilizarse para nuevos archivos, lo que reducirá la capacidad de almacenamiento del sistema de archivos. Reorganizar los pasos tampoco soluciona el problema. Si el paso 3 precediera 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 borrado contendría parte del contenido de otro archivo, y las modificaciones realizadas a cualquiera de los archivos se reflejarían en ambos. Por otro lado, si el paso 2 precediera al paso 1, un fallo entre ellos provocaría que el archivo fuera inaccesible, a pesar de que aparentemente existiera.
La detección y recuperación 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 ] Esto generalmente debe hacerse antes de que el sistema de archivos se monte nuevamente para acceso de lectura y escritura. Si el sistema de archivos es grande y el ancho de banda de E/S es relativamente pequeño, esto puede llevar mucho tiempo y resultar en tiempos de inactividad más prolongados si impide que el resto del sistema vuelva a estar en línea.
Para evitar esto, un sistema de archivos con registro de transacciones asigna un área especial —el registro— donde guarda los cambios que realizará con antelación. Tras un fallo, la recuperación consiste simplemente en leer el registro del sistema de archivos y reproducir los cambios desde este registro hasta que el sistema de archivos vuelva a ser coherente. Por lo tanto, se dice que los cambios son atómicos (no divisibles) porque o bien se realizan correctamente (se realizaron correctamente desde el principio 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 el fallo).
Técnicas
Algunos sistemas de archivos permiten que el registro de transacciones crezca, se reduzca y se reasigne como cualquier otro archivo, mientras que otros lo ubican en un área contigua o en un archivo oculto que garantiza que no se mueva ni cambie de tamaño mientras el sistema de archivos esté montado. Algunos sistemas de archivos también permiten registros externos en un dispositivo independiente, como una unidad de estado sólido o una memoria RAM no volátil con respaldo de batería. Los cambios en el registro pueden registrarse para mayor redundancia, o bien, el registro puede distribuirse entre varios volúmenes físicos para protegerse contra fallos del dispositivo.
El formato interno del registro debe proteger contra fallos mientras se está escribiendo en él. Muchas implementaciones de registro (como la capa JBD2 en ext4 ) delimitan cada cambio registrado con una suma de verificación, partiendo de la base de que un fallo dejaría un cambio escrito parcialmente con una suma de verificación faltante (o incorrecta) que simplemente se puede ignorar al reproducir el registro en el siguiente montaje.
Revistas físicas
Un registro físico guarda una copia anticipada de cada bloque que se escribirá posteriormente en el sistema de archivos principal. Si se produce un fallo durante la escritura en el sistema de archivos principal, la operación se puede repetir hasta completarse la próxima vez que se monte el sistema de archivos. Si se produce un fallo durante el registro de la escritura en el diario, la escritura parcial tendrá una suma de comprobación faltante o incorrecta y se podrá ignorar en el siguiente montaje.
Los diarios físicos imponen una penalización de rendimiento significativa porque cada bloque modificado debe confirmarse dos veces en el almacenamiento, pero pueden ser aceptables cuando se requiere protección absoluta contra fallos. [ 8 ]
Revistas lógicas
Un registro lógico almacena únicamente los cambios en los metadatos de los archivos y ofrece un rendimiento de escritura considerablemente mejor a cambio de una menor tolerancia a fallos. [ 9 ] Un sistema de archivos con un registro lógico se recupera rápidamente tras un fallo, pero puede permitir que los datos de archivos no registrados y los metadatos registrados se desincronicen, lo que provoca corrupción de datos.
Por ejemplo, agregar contenido a un archivo puede implicar tres escrituras separadas en:
- El inodo del archivo , para indicar en los metadatos del archivo que su tamaño ha aumentado.
- El mapa de espacio libre sirve para delimitar la asignación de espacio para los datos que se añadirán posteriormente.
- El espacio recién asignado se utilizará para escribir los datos añadidos.
En un registro que solo contiene metadatos, el paso 3 no se registraría. Si no se realiza el paso 3, pero se repiten los pasos 1 y 2 durante la recuperación, se añadirán datos basura al archivo.
Escribir peligros
La caché de escritura en la mayoría de los sistemas operativos ordena las escrituras (mediante el algoritmo del elevador o un esquema similar) para maximizar el rendimiento. Para evitar un riesgo de escritura fuera de orden con un registro que solo contiene metadatos, las escrituras de datos de archivos deben ordenarse de manera que se guarden en el almacenamiento antes que sus metadatos asociados. Esto puede ser difícil de implementar, ya que 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, si no puede vaciar su caché de escritura en el disco debido a que la escritura diferida está habilitada.
Para complicar aún más las cosas, muchos dispositivos de almacenamiento masivo tienen sus propias cachés de escritura, en las que pueden reordenar agresivamente las escrituras para mejorar el rendimiento. (Esto es particularmente común en discos duros magnéticos, que tienen grandes latencias de búsqueda que se pueden minimizar con la ordenación por elevación). Algunos sistemas de archivos con registro asumen de forma conservadora que dicha reordenación de escrituras siempre tiene lugar y sacrifican el rendimiento en aras de la corrección, obligando al dispositivo a vaciar su caché en ciertos puntos del registro (denominados barreras en ext3 y ext4 ). [ 10 ]
Alternativas
Actualizaciones suaves
Algunas implementaciones de UFS evitan el registro de transacciones y, en su lugar, implementan actualizaciones suaves : ordenan sus escrituras de tal manera que el sistema de archivos en disco nunca sea inconsistente, o que la única inconsistencia que puede crearse en caso de un fallo sea una fuga de almacenamiento. Para recuperarse de estas fugas, 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 ]
Sistemas de archivos estructurados en registros
En los sistemas de archivos con estructura de registro , la penalización por escritura doble no se aplica porque el propio diario es el sistema de archivos: ocupa todo el dispositivo de almacenamiento y está estructurado de tal manera que se puede recorrer como un sistema de archivos normal.
Sistemas de archivos de copia en escritura
Los sistemas de archivos de copia en escritura completa (como ZFS y Btrfs ) evitan las modificaciones directas de los datos de los archivos escribiendo los datos en bloques recién asignados, seguidos de metadatos actualizados que apuntan a los nuevos datos y descartan los antiguos, luego metadatos que apuntan a estos últimos, y así sucesivamente hasta el superbloque, o la raíz de la jerarquía del sistema de archivos. Esto ofrece las mismas propiedades de preservación de la integridad que un registro de transacciones, sin la sobrecarga de la doble escritura.
Véase también
Referencias
- 1 2 Jones, M Tim (4 de junio de 2008), Anatomía de los sistemas de archivos con registro de transacciones de Linux , IBM DeveloperWorks, archivado del original el 21 de febrero de 2009 , recuperado el 13 de abril de 2009.
- 1 2 Arpaci-Dusseau, Remzi H.; Arpaci-Dusseau, Andrea C. (21 de enero de 2014), Crash Consistency: FSCK and Journaling (PDF) , Arpaci-Dusseau Books, archivado (PDF) del original el 24 de enero de 2014 , recuperado el 22 de enero de 2014
- ↑ "tune2fs(8) – Página man de Linux" . linux.die.net . Archivado del original el 25 de febrero de 2015. Consultado el 20 de febrero de 2015 .
- ↑ Chang, A.; Mergen, MF; Rader, RK; Roberts, JA; Porter, SL (enero de 1990), "Evolución de las instalaciones de almacenamiento en AIX Versión 3 para procesadores RISC System/6000" (PDF) , IBM Journal of Research and Development , 34:1 : 105–109 , doi : 10.1147/rd.341.0105
- ↑ Rosenblum, Mendel; Ousterhout, John (febrero de 1991). El diseño e implementación de un sistema de archivos con estructura de registro (PDF) . XIII Simposio anual de la ACM sobre principios de sistemas operativos.
- ↑ "'2.4.15-final' - MARC" . marc.info . Consultado el 24 de marzo de 2018 .
- ↑ Sistemas de archivos de Tanenbaum, AS (2008). Sistemas operativos modernos (3.ª ed., pág. 287). Upper Saddle River, NJ: Prentice Hall.
- ↑ Tweedie, Stephen ( 2000), "Ext3, sistema de archivos con registro de transacciones", Actas del Simposio Linux de Ottawa : 24–29
- ↑ Prabhakaran, Vijayan; Arpaci-Dusseau, Andrea C; Arpaci-Dusseau, Remzi H, "Análisis y evolución de los sistemas de archivos con registro de transacciones" (PDF) , Conferencia Técnica Anual de USENIX de 2005 , Asociación USENIX, archivado (PDF) del original el 26 de septiembre de 2007 , recuperado el 27 de julio de 2007..
- ↑ Corbet, Jonathan (21 de mayo de 2008), Barreras y sistemas de archivos de registro , archivado del original el 14 de marzo de 2010 , recuperado el 6 de marzo de 2010.
- ↑ Seltzer, Margo I; Ganger, Gregory R; McKusick, M Kirk, "Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems" , 2000 USENIX Annual Technical Conference , USENIX Association, archivado del original el 26 de octubre de 2007 , recuperado el 27 de julio de 2007..
- Sistemas de archivos informáticos