ext3 , o tercer sistema de archivos extendido , es un sistema de archivos registrado comúnmente utilizado por el kernel de Linux . Solía ser el sistema de archivos predeterminado para muchas distribuciones populares de Linux . Stephen Tweedie reveló por primera vez que estaba trabajando en la extensión de ext2 en Journaling the Linux ext2fs Filesystem en un artículo de 1998, y más tarde en una publicación en la lista de correo del kernel de febrero de 1999. El sistema de archivos se fusionó con el kernel principal de Linux en noviembre de 2001 desde la versión 2.4.15 en adelante. [3] [4] [5] Su principal ventaja sobre ext2 es el registro en diario , que mejora la confiabilidad y elimina la necesidad de verificar el sistema de archivos después de un cierre incorrecto. Su sucesor es ext4 . [6]
El rendimiento (velocidad) de ext3 es menos atractivo que el de los sistemas de archivos Linux de la competencia, como ext4, JFS , ReiserFS y XFS , pero ext3 tiene una ventaja significativa porque permite actualizaciones in situ desde ext2 sin tener que realizar copias de seguridad ni restaurar datos. . Los puntos de referencia sugieren que ext3 también utiliza menos potencia de CPU que ReiserFS y XFS. [7] [8] También se considera más seguro que otros sistemas de archivos de Linux, debido a su relativa simplicidad y su base de pruebas más amplia. [9] [10]
ext3 agrega las siguientes características a ext2:
Sin estas características, cualquier sistema de archivos ext3 también es un sistema de archivos ext2 válido. Esta situación ha permitido que las utilidades de mantenimiento de sistemas de archivos maduras y bien probadas para mantener y reparar sistemas de archivos ext2 también se utilicen con ext3 sin cambios importantes. Los sistemas de archivos ext2 y ext3 comparten el mismo conjunto estándar de utilidades, e2fsprogs , que incluye una herramienta fsck . La estrecha relación también hace que la conversión entre los dos sistemas de archivos (tanto hacia adelante a ext3 como hacia atrás a ext2) sea sencilla.
ext3 carece de características "modernas" del sistema de archivos, como la asignación dinámica de inodos y las extensiones . Esta situación a veces puede ser una desventaja, pero en términos de recuperabilidad es una ventaja significativa. Todos los metadatos del sistema de archivos se encuentran en ubicaciones fijas y conocidas, y las estructuras de datos tienen cierta redundancia. En caso de corrupción importante de datos, ext2 o ext3 pueden ser recuperables, mientras que un sistema de archivos basado en árbol puede no serlo.
El número máximo de bloques para ext3 es 2 32 . El tamaño de un bloque puede variar, afectando la cantidad máxima de archivos y el tamaño máximo del sistema de archivos: [12]
Hay tres niveles de registro en diario disponibles en la implementación de ext3 en Linux:
En los tres modos, se garantiza que la estructura interna del sistema de archivos será consistente incluso después de una falla. En cualquier caso, sólo se verán afectados los contenidos de datos de archivos o directorios que estuvieran siendo modificados cuando el sistema falló; el resto quedará intacto después de la recuperación.
Debido a que ext3 pretende ser compatible con versiones anteriores del ext2 anterior, muchas de las estructuras en el disco son similares a las de ext2. En consecuencia, ext3 carece de características recientes, como extensiones , asignación dinámica de inodos y subasignación de bloques. [15] Un directorio puede tener como máximo 31998 subdirectorios , porque un inodo puede tener como máximo 32.000 enlaces (cada subdirectorio directo aumenta el contador de enlaces de inodo de su carpeta principal en la referencia ".."). [dieciséis]
En ext3, como ocurre con la mayoría de los sistemas de archivos Linux actuales, la herramienta del sistema " fsck " no debe usarse mientras el sistema de archivos está montado para escritura. [6] Intentar verificar un sistema de archivos que ya está montado en modo lectura/escritura detectará (muy probablemente) inconsistencias en los metadatos del sistema de archivos. Cuando los metadatos del sistema de archivos están cambiando y fsck aplica cambios en un intento de llevar los metadatos "inconsistentes" a un estado "consistente", el intento de "arreglar" las inconsistencias dañará el sistema de archivos.
No existe ninguna herramienta de desfragmentación ext3 en línea que funcione a nivel del sistema de archivos. Hay un desfragmentador ext2 fuera de línea, e2defrag. Sin embargo, e2defragpuede destruir datos, dependiendo de los bits de función activados en el sistema de archivos; no sabe cómo manejar muchas de las funciones más nuevas de ext3. [17]
Existen herramientas de desfragmentación del espacio de usuario, como Shake [18] y defrag. [19] [20] Shake funciona asignando espacio para todo el archivo como una sola operación, lo que generalmente hará que el asignador encuentre espacio en disco contiguo. Si hay archivos que se utilizan al mismo tiempo, Shake intentará escribirlos uno al lado del otro. Defrag funciona copiando cada archivo sobre sí mismo. Sin embargo, esta estrategia sólo funciona si el sistema de archivos tiene suficiente espacio libre. No existe una verdadera herramienta de desfragmentación para ext3. [21]
Sin embargo, como indica la Guía del administrador del sistema Linux, "los sistemas de archivos Linux modernos mantienen la fragmentación al mínimo al mantener todos los bloques de un archivo juntos, incluso si no se pueden almacenar en sectores consecutivos. Algunos sistemas de archivos, como ext3, "Asignar efectivamente el bloque libre más cercano a otros bloques en un archivo. Por lo tanto, no es necesario preocuparse por la fragmentación en un sistema Linux". [22]
Si bien ext3 es resistente a la fragmentación de archivos, ext3 puede fragmentarse con el tiempo o debido a patrones de uso específicos, como escribir archivos grandes lentamente. [23] [24] En consecuencia, ext4 (el sucesor de ext3) tiene una utilidad de desfragmentación del sistema de archivos en línea e4defrag [25] y actualmente admite extensiones (regiones de archivos contiguas).
ext3 no admite la recuperación de archivos eliminados. El controlador ext3 elimina archivos activamente limpiando los inodos del archivo [26] por razones de seguridad en caso de colisión.
Todavía existen varias técnicas [27] y algunos programas gratuitos [28] y propietarios [29] para recuperar archivos eliminados o perdidos mediante el análisis del diario del sistema de archivos; sin embargo, no garantizan la recuperación de ningún archivo específico.
e3compr [30] es un parche no oficial para ext3 que realiza compresión transparente . Es una adaptación directa de e2compr y aún necesita mayor desarrollo. Se compila y arranca bien con kernels ascendentes [ cita necesaria ] , pero el registro en diario aún no está implementado.
A diferencia de varios sistemas de archivos modernos, ext3 no tiene soporte nativo para instantáneas , la capacidad de capturar rápidamente el estado del sistema de archivos en momentos arbitrarios. En cambio, se basa en instantáneas a nivel de volumen que ocupan menos espacio y que proporciona Linux LVM . El sistema de archivos Next3 es una versión modificada de ext3 que ofrece soporte para instantáneas, pero conserva la compatibilidad con el formato ext3 en disco. [31]
ext3 no realiza sumas de verificación al escribir en el diario. En un dispositivo de almacenamiento con caché adicional, si barrier=1 no está habilitado como opción de montaje (en /etc/fstab ) y si el hardware realiza un almacenamiento en caché de escritura desordenado, se corre el riesgo de sufrir una corrupción grave del sistema de archivos durante el proceso. un choque. [32] [33] [34] Esto se debe a que los dispositivos de almacenamiento con cachés de escritura informan al sistema que los datos se han escrito por completo, incluso si se escribieron en el caché (volátil).
Si las escrituras en el disco duro se realizan desordenadas (debido a que los discos duros modernos almacenan en caché las escrituras para amortizar las velocidades de escritura), es probable que se escriba un bloque de confirmación de una transacción antes de que se escriban los otros bloques relevantes. Si se produce un corte de energía o un bloqueo irrecuperable antes de que se escriban los otros bloques, será necesario reiniciar el sistema. Al reiniciar, el sistema de archivos reproducirá el registro normalmente y reproducirá los "ganadores" (transacciones con un bloque de confirmación, incluida la transacción no válida anterior, que resultó estar etiquetada con un bloque de confirmación válido). La escritura en disco inacabada anterior continuará, pero utilizando datos de diario corruptos. Por lo tanto, el sistema de archivos sobrescribirá por error los datos normales con datos corruptos mientras reproduce el diario. Si se hubieran utilizado sumas de verificación, donde los bloques de la transacción del "falso ganador" estuvieran etiquetados con una suma de verificación mutua, el sistema de archivos podría haberlo sabido mejor y no reproducir los datos corruptos en el disco. Se agregó la suma de verificación del diario a ext4. [35]
Es posible que los sistemas de archivos que pasan por la interfaz del asignador de dispositivos (incluidas las implementaciones de software RAID y LVM) no admitan barreras y emitirán una advertencia si se utiliza esa opción de montaje. [36] [37] También hay algunos discos que no implementan correctamente la extensión de vaciado de caché de escritura necesaria para que funcionen las barreras, lo que provoca una advertencia similar. [38] En estas situaciones, donde las barreras no son compatibles o no son prácticas, es posible realizar un orden de escritura confiable desactivando el caché de escritura del disco y usando la data=journalopción de montaje. [32] Es posible que sea necesario desactivar la caché de escritura del disco incluso cuando haya barreras disponibles.
Las aplicaciones como las bases de datos esperan una llamada a fsync() para vaciar las escrituras pendientes en el disco, y la implementación de la barrera no siempre borra el caché de escritura de la unidad en respuesta a esa llamada. [39] También existe un problema potencial con la implementación de la barrera relacionada con el manejo de errores durante eventos, como una falla en la unidad. [40] También se sabe que a veces algunas tecnologías de virtualización no reenvían correctamente los comandos fsync o vaciado a los dispositivos subyacentes (archivos, volúmenes, disco) desde un sistema operativo invitado. [41] De manera similar, algunos discos duros o controladores implementan el vaciado de caché de manera incorrecta o no lo implementan en absoluto, pero aun así anuncian que es compatible y no devuelven ningún error cuando se usa. [42] Hay tantas maneras de manejar fsync y escribir el manejo de caché incorrectamente, que es más seguro asumir que el vaciado de caché no funciona a menos que se pruebe explícitamente, independientemente de cuán confiables se crean que son los componentes individuales.
Ext3 almacena fechas como hora Unix usando cuatro bytes en el encabezado del archivo. 32 bits no ofrecen suficiente margen para continuar procesando archivos más allá del 18 de enero de 2038: el problema del año 2038 . [43]
El 28 de junio de 2006, Theodore Ts'o , el principal desarrollador de ext3, [44] anunció una versión mejorada, llamada ext4. El 11 de octubre de 2008, los parches que marcan ext4 como código estable se fusionaron en los repositorios de código fuente de Linux 2.6.28, marcando el final de la fase de desarrollo y recomendando su adopción. En 2008, Ts'o afirmó que aunque ext4 tiene características mejoradas, como ser mucho más rápido que ext3, no es un avance importante, utiliza tecnología antigua y es una solución provisional; Ts'o cree que Btrfs es la mejor dirección, porque "ofrece mejoras en escalabilidad, fiabilidad y facilidad de gestión". [45] Btrfs también tiene "varias de las mismas ideas de diseño que tenía reiser3 / 4 ". [46]
{{cite journal}}: Citar diario requiere |journal=( ayuda )El sistema de archivos predeterminado de Ubuntu ("ext3") fragmentará archivos grandes (>1 GB) y de crecimiento lento (<1 MB/s).
Encontramos áreas libres muy fragmentadas en un servidor IMAP de uso intensivo que almacena todos sus correos electrónicos en archivos individuales, aunque todavía estaban disponibles más de 900 GB del espacio total en disco de 1,4 TB.