ext2

ext2 , o segundo sistema de archivos extendido , es un sistema de archivos para el núcleo Linux . Fue diseñado inicialmente por el desarrollador de software francés Rémy Card como reemplazo del sistema de archivos extendido (ext). Al haber sido diseñado de acuerdo con los mismos principios que el Berkeley Fast File System de BSD , fue el primer sistema de archivos de calidad comercial para Linux. ^[7]

La implementación canónica de ext2 es el controlador del sistema de archivos "ext2fs" en el núcleo Linux. Existen otras implementaciones (de diversa calidad y completitud) en GNU Hurd , ^[8] MINIX 3 , ^{[9] [10]} algunos núcleos BSD , ^{[11] [12] [13]} en MiNT , ^[14] Haiku ^[15] y como controladores de terceros para Microsoft Windows ^[16] y macOS (a través de FUSE ). Este controlador quedó obsoleto en la versión 6.9 de Linux a favor del controlador ext4, ya que el controlador ext4 funciona con sistemas de archivos ext2. ^[17]

ext2 fue el sistema de archivos predeterminado en varias distribuciones Linux , incluidas Debian y Red Hat Linux , hasta que fue reemplazado por ext3 , que es casi completamente compatible con ext2 y es un sistema de archivos con registro en diario . ext2 sigue siendo el sistema de archivos de elección para los medios de almacenamiento basados ​​en flash (como tarjetas SD y unidades flash USB ) ^{[ cita requerida ]} porque su falta de un registro en diario aumenta el rendimiento y minimiza la cantidad de escrituras, y los dispositivos flash pueden soportar una cantidad limitada de ciclos de escritura. Desde 2009, ^[18] el núcleo Linux admite un modo sin registro en diario de ext4 que proporciona beneficios que no se encuentran en ext2, como tamaños de archivo y volumen más grandes. ^[19]

El desarrollo inicial del núcleo Linux se realizó como un desarrollo cruzado bajo el sistema operativo MINIX . El sistema de archivos MINIX se utilizó como el primer sistema de archivos de Linux. El sistema de archivos Minix estaba mayormente libre de errores , pero utilizaba desplazamientos de 16 bits internamente y, por lo tanto, tenía un límite de tamaño máximo de solo 64 megabytes , y también había un límite de longitud de nombre de archivo de 14 caracteres. ^[20] Debido a estas limitaciones, se comenzó a trabajar en un sistema de archivos nativo de reemplazo para Linux. ^[20]

Para facilitar la adición de nuevos sistemas de archivos y proporcionar una API de archivos genérica , se agregó VFS , una capa de sistema de archivos virtual, al núcleo de Linux. El sistema de archivos extendido ( ext ), se lanzó en abril de 1992 como el primer sistema de archivos que usaba la API VFS y se incluyó en la versión 0.96c de Linux. ^[21] El sistema de archivos ext resolvió los dos problemas principales del sistema de archivos Minix (tamaño máximo de partición y limitación de longitud de nombre de archivo a 14 caracteres), y permitió 2 gigabytes de datos y nombres de archivo de hasta 255 caracteres. Pero aún tenía problemas: no había soporte para marcas de tiempo separadas para acceso a archivos, modificación de inodos y modificación de datos.

Como solución a estos problemas, en enero de 1993 se desarrollaron dos nuevos sistemas de archivos para el kernel Linux 0.99: xiafs y el segundo sistema de archivos extendido ( ext2 ), ^[21] que fue una revisión del sistema de archivos extendido que incorporaba muchas ideas del Berkeley Fast File System . ext2 también fue diseñado teniendo en mente la extensibilidad, dejando espacio en muchas de sus estructuras de datos en disco para su uso en futuras versiones. ^{[ cita requerida ]}

Desde entonces, ext2 ha sido un banco de pruebas para muchas de las nuevas extensiones de la API de VFS. Las características como la propuesta de ACL de borrador de POSIX retirada y la propuesta de atributo extendido retirada generalmente se implementaron primero en ext2 porque era relativamente simple de extender y sus componentes internos se entendían bien.

En los kernels de Linux anteriores a 2.6.17, ^[22] las restricciones en el controlador de bloque significan que los sistemas de archivos ext2 tienen un tamaño de archivo máximo de 2 TiB.

Todavía se recomienda ext2 en lugar de sistemas de archivos con registro en diario en unidades flash USB de arranque y otras unidades de estado sólido ^{[ ¿por quién? ]} . ext2 realiza menos escrituras que ext3 porque no hay registro en diario. Como el principal factor de envejecimiento de un chip flash es la cantidad de ciclos de borrado, y como los ciclos de borrado ocurren con frecuencia en las escrituras, la disminución de las escrituras aumenta la vida útil del dispositivo de estado sólido. ^[23] Otra buena práctica para los sistemas de archivos en dispositivos flash es el uso de la opción de montaje no atime , por la misma razón.

A partir del kernel de Linux 6.9, el controlador ext2fs quedó obsoleto y ya no está habilitado en la configuración predeterminada. La razón principal fue que no admitía fechas posteriores a 2038. [ ^17] Se recomienda a los usuarios que actualicen a ext4. ^[24]

Esta sección necesita citas adicionales para su verificación . Por favor, ayude a mejorar este artículo añadiendo citas de fuentes confiables en esta sección. El material sin fuentes puede ser cuestionado y eliminado. ( Enero de 2017 ) ( Aprenda cómo y cuándo eliminar este mensaje )

El espacio en ext2 se divide en bloques . Estos bloques se agrupan en grupos de bloques, de forma análoga a los grupos de cilindros en el sistema de archivos Unix . Normalmente, hay miles de bloques en un sistema de archivos grande. Los datos de cualquier archivo determinado suelen estar contenidos dentro de un único grupo de bloques siempre que sea posible. Esto se hace para minimizar la cantidad de búsquedas en el disco cuando se leen grandes cantidades de datos contiguos.

Cada grupo de bloques contiene una copia del superbloque y la tabla de descriptores del grupo de bloques, y todos los grupos de bloques contienen un mapa de bits de bloques, un mapa de bits de inodo, una tabla de inodo y, finalmente, los bloques de datos reales.

El superbloque contiene información importante que resulta crucial para el arranque del sistema operativo . Por ello, se realizan copias de seguridad en varios grupos de bloques del sistema de archivos. Sin embargo, normalmente solo se utiliza en el arranque la primera copia del mismo, que se encuentra en el primer bloque del sistema de archivos.

El descriptor de grupo almacena la ubicación del mapa de bits del bloque, el mapa de bits del inodo y el inicio de la tabla de inodos para cada grupo de bloques. Estos, a su vez, se almacenan en una tabla de descriptores de grupo.

Cada archivo o directorio está representado por un inodo . El término "inodo" proviene de "nodo de índice" (con el tiempo, se convirtió en i-nodo y luego en inodo). ^[25] El inodo incluye datos sobre el tamaño, los permisos, la propiedad y la ubicación en el disco del archivo o directorio.

Ejemplo de estructura de inodo ext2:

Cita de la documentación del kernel de Linux para ext2: ^[26]

Hay punteros a los primeros 12 bloques que contienen los datos del archivo en el inodo. Hay un puntero a un bloque indirecto (que contiene punteros al siguiente conjunto de bloques), un puntero a un bloque doblemente indirecto y un puntero a un bloque triplemente indirecto.

Por lo tanto, hay una estructura en ext2 que tiene 15 punteros. Los punteros 1 a 12 apuntan a bloques directos, el puntero 13 apunta a un bloque indirecto, el puntero 14 apunta a un bloque doblemente indirecto y el puntero 15 apunta a un bloque triplemente indirecto.

Cada directorio es una lista de entradas de directorio. Cada entrada de directorio asocia un nombre de archivo con un número de inodo, y consta del número de inodo, la longitud del nombre de archivo y el texto real del nombre de archivo. Para encontrar un archivo, se busca el directorio de principio a fin para encontrar el nombre de archivo asociado. Para directorios de tamaño razonable, esto está bien. Pero para directorios muy grandes esto es ineficiente, y ext3 ofrece una segunda forma de almacenar directorios ( HTree ) que es más eficiente que una simple lista de nombres de archivo.

El directorio raíz siempre se almacena en el inodo número dos, de modo que el código del sistema de archivos pueda encontrarlo en el momento del montaje. Los subdirectorios se implementan almacenando el nombre del subdirectorio en el campo de nombre y el número de inodo del subdirectorio en el campo de inodo. Los enlaces duros se implementan almacenando el mismo número de inodo con más de un nombre de archivo. Acceder al archivo por cualquiera de los nombres da como resultado el mismo número de inodo y, por lo tanto, los mismos datos.

Los directorios especiales "." (directorio actual) y ".." (directorio padre) se implementan almacenando los nombres "." y ".." en el directorio, y el número de inodo del directorio actual y padre en el campo de inodo. El único tratamiento especial que reciben estas dos entradas es que se crean automáticamente cuando se crea un nuevo directorio y no se pueden eliminar.

Cuando se crea un nuevo archivo o directorio, ext2 debe decidir dónde almacenar los datos. Si el disco está casi vacío, los datos se pueden almacenar prácticamente en cualquier lugar. Sin embargo, agrupar los datos con datos relacionados minimizará los tiempos de búsqueda y maximizará el rendimiento.

ext2 intenta asignar cada nuevo directorio en el grupo que contiene su directorio padre, basándose en la teoría de que los accesos a los directorios padre e hijos probablemente estén estrechamente relacionados. ext2 también intenta colocar los archivos en el mismo grupo que sus entradas de directorio, porque los accesos a directorios a menudo conducen a accesos a archivos. Sin embargo, si el grupo está lleno, entonces el nuevo archivo o directorio se coloca en algún otro grupo que no esté lleno.

Los bloques de datos necesarios para almacenar directorios y archivos se pueden encontrar consultando el mapa de bits de asignación de datos. El espacio necesario en la tabla de inodos se puede encontrar consultando el mapa de bits de asignación de inodos.

This bit possibly contains original research. There are lots of calculations and numbers, all unsourced. (Can ext2 even have a 512-byte block size?) Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (December 2021) (Learn how and when to remove this message)

La razón de algunas limitaciones de ext2 son el formato de archivo de los datos y el núcleo del sistema operativo. En su mayoría, estos factores se determinarán una vez que se construya el sistema de archivos. Dependen del tamaño de bloque y de la relación entre el número de bloques e inodos. ^{[ cita requerida ] En Linux, el tamaño de bloque está limitado por el} tamaño de página de la arquitectura .

También hay algunos programas de espacio de usuario que no pueden manejar archivos de más de 2 GiB .

Si b es el tamaño del bloque, el tamaño máximo del archivo está limitado a min( (( b /4) ³ + ( b /4) ² + b /4 + 12) × b , (2 ³² − 1) × 512 ) debido a la estructura i_block (una matriz de EXT2_N_BLOCKS directos/indirectos) e i_blocks (valor entero de 32 bits) que representa la cantidad de 1024 bytes (1 kilobyte) ^[28] "bloques" en el archivo. ^{[ ¿ investigación original? ]}

El número máximo de subdirectorios es 31998, debido al límite de recuento de enlaces. ^{[ cita requerida ]} La indexación de directorios no está disponible en ext2, por lo que existen problemas de rendimiento para directorios con una gran cantidad de archivos (>10 000). El límite teórico en la cantidad de archivos en un directorio es 1,3 × 10 ²⁰ , ^{[ investigación original? ]} aunque esto no es relevante para situaciones prácticas.

Nota: En Linux 2.4 y versiones anteriores, los dispositivos de bloque estaban limitados a 2 TiB, lo que limitaba el tamaño máximo de una partición, independientemente del tamaño del bloque. ^{[ cita requerida ]}

e2compr es una modificación del controlador ext2 en el kernel de Linux para soportar la compresión y descompresión de archivos por parte del sistema de archivos, sin ningún soporte por parte de las aplicaciones del usuario. e2compr es un pequeño parche contra ext2.

e2compr comprime únicamente archivos normales; los datos administrativos (superbloques, inodos, archivos de directorio , etc.) no se comprimen (principalmente por razones de seguridad). Se proporciona acceso a los bloques comprimidos para operaciones de lectura y escritura. El algoritmo de compresión y el tamaño del clúster se especifican para cada archivo. Los directorios también se pueden marcar para compresión, en cuyo caso cada archivo recién creado en el directorio se comprimirá automáticamente con el mismo tamaño de clúster y el mismo algoritmo que se especificó para el directorio.

e2compr no es un nuevo sistema de archivos. Es solo un parche para ext2 creado para soportar el indicador EXT2_COMPR_FL. No requiere que el usuario cree una nueva partición y continuará leyendo o escribiendo sistemas de archivos ext2 existentes. Se puede considerar simplemente como una forma para que las rutinas de lectura y escritura accedan a archivos que podrían haber sido creados por una utilidad simple similar a gzip o compress. Los archivos comprimidos y sin comprimir coexisten perfectamente en particiones ext2.

La última rama e2compr está disponible para las versiones actuales de Linux 2.4, 2.6 y 3.0. El último parche para Linux 3.0 se publicó en agosto de 2011 y ofrece compatibilidad con múltiples núcleos y alta memoria . También hay ramas para Linux 2.0 y 2.2.

El acceso a particiones ext2 en Microsoft Windows es posible a través de un sistema de archivos instalable , como ext2ifs ^[29] o ext2Fsd ^[30 ]. El sistema de archivos en el espacio de usuario se puede utilizar en macOS. ^[31]

• Programas e2fs
• StegFS : un sistema de archivos esteganográfico basado en ext2
• cloop
• Lista de sistemas de archivos
• Comparación de sistemas de archivos
• Asignador de bloques Orlov , kernel de Linux : asignador de bloques predeterminado determinado para ext2. ^[32]

• John Newbigin. "Especificación de John del segundo sistema de archivos extendido". {{cite journal}}: Requiere citar revista |journal=( ayuda )
• Dave Poirier (2009). "El segundo sistema de archivos extendido: diseño interno". {{cite journal}}: Requiere citar revista |journal=( ayuda )
• Theodore Ts'o; Stephen Tweedie (junio de 2002). "Extensiones planificadas para el sistema de archivos Ext2/Ext3 de Linux". Conferencia técnica anual de USENIX 2002 .
• Larry Ayers (junio de 1997). "E2compr: Compresión transparente de archivos para Linux". Linux Gazette (18). Archivado desde el original el 17 de noviembre de 2009.
• Charles Cong; Jeremy H. Brown (26 de diciembre de 1997). "Un sistema para la compresión transparente de archivos con almacenamiento en caché en Linux". CiteSeerX  10.1.1.51.4780 . {{cite journal}}: Requiere citar revista |journal=( ayuda )
• Charles Cong; Jeremy H. Brown (22 de octubre de 1997). "Un estudio de las técnicas modernas de compresión de archivos". CiteSeerX  10.1.1.50.9847 . {{cite journal}}: Requiere citar revista |journal=( ayuda )

• herramientas de espacio de usuario de ext2fs
• Controlador de sistema de archivos ext2/ext3 GPL Ext3Fsd para Windows 2000/XP/2003/VISTA/2008 (código abierto, admite lectura y escritura, funciona con FreeOTFE)