Tux3 es un sistema de archivos de control de versiones de código abierto creado por Daniel Phillips. Introdujo el sistema de archivos como un reemplazo público de su sistema de archivos Tux2 que había encontrado problemas de licencia debido a la presentación de varias patentes. [1] Phillips había creado previamente el sistema de indexación de directorios Htree que eventualmente se convirtió en una característica oficial de ext3 . [2] Los detalles técnicos de Tux3 se publicaron por primera vez en un correo electrónico el 23 de julio de 2008. [3]
En líneas generales, Tux3 sigue un diseño de directorio / archivo / inodo de estilo Unix convencional . Una tabla de inodo Tux3 es un árbol B con atributos versionados en las hojas. Un archivo es un atributo de inodo que es un árbol B con extensiones versionadas en las hojas. Los índices de directorio se asignan a bloques de archivos de directorio como con Htree. El espacio libre está mapeado por un árbol B con extensiones en las hojas. Intenta evitar el registro en diario tradicional mediante la introducción de una lógica de recuperación que le permite recuperarse al volver a montar. [4]
Un inodo Tux3 es un objeto de tamaño variable que consta de una lista de atributos, cada uno etiquetado por la versión en la que se agregó, modificó o eliminó el atributo. El índice de árbol B por el que se hace referencia a los inodos no está versionado. El índice de árbol B de un archivo grande tampoco está versionado, a excepción de las hojas del índice, que contienen listas de extensiones, cada una etiquetada por la versión en la que se agregaron o cambiaron los datos del archivo de referencia. Este estilo de control de versiones es esencialmente el inverso de los métodos de control de versiones de árbol utilizados por Write Anywhere File Layout (WAFL), ZFS y Btrfs , donde se crean múltiples raíces de árbol de un sistema de archivos completo para expresar las diferencias entre las versiones del sistema de archivos.
Una ventaja declarada de las entidades versionadas al estilo Tux3 es que solo se deben agregar unos pocos bytes para representar cambios únicos en los atributos de inodo o para indexar nuevas versiones de bloques de datos de archivo, en comparación con una cierta cantidad de bloques de índice que deben asignarse y escribirse para el árbol. -sistemas de archivos con versiones.
En agosto de 2008, Tux3 solo era capaz de realizar operaciones de E / S básicas en archivos. A finales de 2008, Tux3 era capaz de ejecutarse dentro del kernel y podía soportar ejecuciones repetidas del ejercitador del sistema de archivos fsx-linux, un gran logro. [5]
El 18 de enero de 2013, se agregó el soporte fsck inicial. [7] Hasta ahora solo verifica la integridad referencial física , pero los desarrolladores confían en que pronto podrán hacer un fsck de calidad e2fsck completamente funcional.