ReiserFS es un sistema de archivos de registro de uso general diseñado e implementado inicialmente por un equipo de Namesys dirigido por Hans Reiser y con licencia GPLv2 . Introducido en la versión 2.4.1 del núcleo Linux , fue el primer sistema de archivos de registro que se incluyó en el núcleo estándar. ReiserFS fue el sistema de archivos predeterminado en SUSE Linux Enterprise de Novell hasta que Novell decidió migrar a ext3 para futuras versiones el 12 de octubre de 2006. [3]
La versión 3.6 de ReiserFS, ahora denominada ocasionalmente Reiser3, introdujo un nuevo formato en disco que permite archivos de mayor tamaño. Namesys consideró que ReiserFS era estable y completo en cuanto a funciones, y cesó su desarrollo para concentrarse en su sucesor, Reiser4 , aunque continuó lanzando actualizaciones de seguridad y correcciones de errores críticos. Namesys cerró en 2008 después de la condena de Reiser por asesinato. El producto ahora se mantiene como código abierto por voluntarios. [4] Las reiserfsprogs 3.6.27 se lanzaron el 25 de julio de 2017. [5]
ReiserFS actualmente es compatible con Linux sin compatibilidad con cuotas. Se ha discutido su eliminación del kernel de Linux desde principios de 2022 debido a la falta de mantenimiento y a problemas técnicos inherentes al sistema de archivos, como el problema del año 2038 ; [6] [7] [8] quedó obsoleto en Linux 5.18, [9] y se marcó como obsoleto en Linux 6.6. [10] Se planea su eliminación en Linux 6.13. [11] [12] [13] [14]
En el momento de su introducción, ReiserFS ofrecía características que no estaban disponibles en los sistemas de archivos Linux existentes, como el empaquetamiento de colas , un esquema para reducir la fragmentación interna a costa del rendimiento. Es posible que Reiser4 haya mejorado esto al empaquetar colas donde no afecten negativamente al rendimiento. [15]
ReiserFS almacena metadatos de archivos ("elementos estadísticos"), entradas de directorio ("elementos de directorio"), listas de bloques de inodos ("elementos indirectos") y colas de archivos ("elementos directos") en un único árbol B+ combinado, codificado por un ID de objeto universal. Los bloques de disco asignados a los nodos del árbol son "bloques internos formateados". Los bloques para los nodos hoja (en los que los elementos se empaquetan de extremo a extremo) son "bloques hoja formateados". Todos los demás bloques son "bloques sin formato" que contienen contenidos de archivos. Los elementos de directorio con demasiadas entradas o elementos indirectos que son demasiado largos para caber en un nodo se desbordan hacia el vecino hoja correcto. La asignación de bloques se rastrea mediante mapas de bits de espacio libre en ubicaciones fijas.
Por el contrario, ext2 y otros sistemas de archivos tipo Berkeley FFS de esa época simplemente usaban una fórmula fija para calcular las ubicaciones de los inodos, lo que limitaba la cantidad de archivos que podían contener. [16] La mayoría de estos sistemas de archivos también almacenan directorios como simples listas de entradas, lo que hace que las búsquedas y actualizaciones de directorios sean operaciones de tiempo lineal y degrada el rendimiento en directorios muy grandes. El diseño de árbol B+ único en ReiserFS evita ambos problemas debido a mejores propiedades de escalabilidad.
En comparación con ext2 y ext3 en la versión 2.4 del kernel de Linux, cuando se trabaja con archivos de menos de 4 KiB y con el empaquetamiento de cola habilitado, ReiserFS puede ser más rápido. [17]
Antes de Linux 2.6.33, [18] ReiserFS usaba intensamente el bloqueo de núcleo grande (BKL), un bloqueo global de todo el núcleo, que no escala bien para sistemas con múltiples núcleos, [19] ya que las partes críticas del código solo las ejecuta un núcleo a la vez.
ReiserFS fue el sistema de archivos predeterminado en SuSE Linux desde la versión 6.4 (lanzada en 2000), [20] [21] hasta cambiar a ext3 en SUSE Linux Enterprise 10.2 y openSUSE 11, anunciado en 2006. [22] [23]
Jeff Mahoney de SUSE escribió un artículo el 14 de septiembre de 2006 proponiendo pasar de ReiserFS a ext3 como sistema de archivos de instalación predeterminado. [19] Las razones que mencionó incluían escalabilidad, "problemas de rendimiento con atributos extendidos y ACL ", "una comunidad de desarrollo pequeña y cada vez más reducida", y que " Reiser4 no es una actualización incremental y requiere un reformateo, lo que no es razonable para la mayoría de las personas". [19] El 4 de octubre escribió un comentario de respuesta en un blog para aclarar algunos problemas. [24] Escribió que su propuesta para el cambio no estaba relacionada con el juicio por asesinato de Hans Reiser. [25] [ verificación fallida ] Mahoney escribió que "estaba preocupado de que la gente hiciera una conexión donde no existía" y que "el momento es completamente coincidente y la motivación no está relacionada". [24]
Algunas operaciones de directorio (incluida la desvinculación (2)) no son sincrónicas en ReiserFS, lo que puede provocar corrupción de datos en aplicaciones que dependen en gran medida de bloqueos basados en archivos (como agentes de transferencia de correo como qmail [26] y Postfix [27] ) si la máquina se detiene antes de haber sincronizado el disco. [28]
No existen programas para desfragmentar específicamente un sistema de archivos ReiserFS, aunque se han escrito herramientas para copiar automáticamente el contenido de los archivos fragmentados con la esperanza de encontrar más bloques contiguos de espacio libre. Sin embargo, se planeó una herramienta de "reempaquetado" para el próximo sistema de archivos Reiser4 para lidiar con la fragmentación de archivos. [29] La fragmentación sigue siendo un problema con los SSD independientemente del sistema de archivos. [30]
El fsck de ReiserFS 3 es capaz de reconstruir todo el árbol como parte del rescate en caso de que esté totalmente dañado. Esta acción debe ser iniciada explícitamente por el administrador y no es parte del funcionamiento normal. Como era de esperar, el proceso es destructivo y puede dañar aún más los archivos existentes o introducir nuevas entradas con contenidos inesperados, lo que ha sido criticado como un método poco óptimo. [31]
Las imágenes de ReiserFS v3 no se deben almacenar en una partición de ReiserFS v3 (por ejemplo, copias de seguridad o imágenes de disco para emuladores) sin transformarlas (por ejemplo, comprimiéndolas o cifrándolas) para evitar confundir la reconstrucción. Reformatear una partición de ReiserFS v3 existente también puede dejar datos que podrían confundir la operación de reconstrucción y hacer que reaparezcan los archivos del sistema anterior. Esto también permite que los usuarios malintencionados almacenen archivos intencionalmente que confundirán al reconstructor. Como los metadatos siempre están en un estado consistente después de una verificación del sistema de archivos, la corrupción aquí significa que el contenido de los archivos se fusiona de formas inesperadas con los metadatos del sistema de archivos contenido. Esto es similar al problema de FSID en btrfs . El sucesor de ReiserFS, Reiser4, soluciona este problema.
ReiserFS en versiones del kernel Linux anteriores a 2.4.16 fue considerado inestable por Namesys y no recomendado para uso en producción, especialmente en conjunto con NFS . [32]
Las primeras implementaciones de ReiserFS (anteriores a la de Linux 2.6.2) también eran susceptibles a los peligros de escritura fuera de orden. Pero la implementación actual de registro en diario en ReiserFS ahora está a la par con el nivel de registro en diario "ordenado" de ext3 . [ cita requerida ]
{{cite web}}: CS1 maint: nombres numéricos: lista de autores ( enlace )