ext3 , o tercer sistema de archivos extendido , es un sistema de archivos con registro que se utiliza habitualmente en el núcleo 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 núcleo en febrero de 1999. El sistema de archivos se fusionó con el núcleo principal de Linux en noviembre de 2001 a partir de la versión 2.4.15. [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 apagado incorrecto. Su sucesor es ext4 . [6]
El rendimiento (velocidad) de ext3 es menos atractivo que los sistemas de archivos Linux de la competencia, como ext4, JFS , ReiserFS y XFS , pero ext3 tiene una ventaja significativa, ya que permite actualizaciones en el lugar desde ext2 sin tener que hacer copias de seguridad y 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 los otros sistemas de archivos Linux, debido a su relativa simplicidad y una 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 es también un sistema de archivos ext2 válido. Esta situación ha permitido que utilidades de mantenimiento de sistemas de archivos probadas y maduras para mantener y reparar sistemas de archivos ext2 también se puedan usar con ext3 sin realizar 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 delante como hacia atrás, hacia ext2) sea sencilla.
Ext3 carece de características de sistema de archivos "modernas", como la asignación dinámica de inodos y extensiones . Esta situación puede ser a veces una desventaja, pero para la capacidad de recuperación es una ventaja significativa. Los metadatos del sistema de archivos están todos en ubicaciones fijas y bien conocidas, y las estructuras de datos tienen cierta redundancia. En caso de corrupción significativa de datos, ext2 o ext3 pueden ser recuperables, mientras que un sistema de archivos basado en árboles puede no serlo.
El número máximo de bloques para ext3 es 2 32 . El tamaño de un bloque puede variar, lo que afecta el número máximo de archivos y el tamaño máximo del sistema de archivos: [12]
Hay tres niveles de registro disponibles en la implementación de Linux de ext3:
En los tres modos, se garantiza que la estructura interna del sistema de archivos sea coherente incluso después de una falla. En cualquier caso, solo se verá afectado el contenido de datos de los archivos o directorios que se estaban modificando cuando el sistema falló; el resto permanecerá intacto después de la recuperación.
Debido a que ext3 pretende ser compatible con versiones anteriores de ext2, muchas de las estructuras en 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 32000 enlaces (cada subdirectorio directo aumenta el contador de enlaces de inodo de su carpeta principal en la referencia ".."). [16]
En ext3, como en la mayoría de los sistemas de archivos Linux actuales, no se debe utilizar la herramienta del sistema " fsck " mientras el sistema de archivos esté montado para escritura. [6] Intentar comprobar un sistema de archivos que ya está montado en modo de 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 los 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 una herramienta de desfragmentación de ext3 en línea que funcione a nivel del sistema de archivos. Existe un desfragmentador de 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 características 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 en 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 funciona solo 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, asignan efectivamente el bloque libre que está más cerca de 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, puede fragmentarse con el tiempo o por patrones de uso específicos, como escribir lentamente archivos grandes. [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 de forma activa borrando los inodos de archivo [26] por razones de seguridad ante fallas.
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 ninguna recuperación de archivos específica.
e3compr [30] es un parche no oficial para ext3 que realiza compresión transparente . Es un puerto directo de e2compr y aún necesita más desarrollo. Se compila y arranca bien con kernels originales [ cita requerida ] , 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 su lugar, se basa en instantáneas a nivel de volumen que ocupan menos espacio y que proporciona el LVM de Linux . 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 en disco ext3. [31]
ext3 no realiza la suma de comprobación al escribir en el diario. En un dispositivo de almacenamiento con caché adicional, si barrier=1 no está habilitado como una opción de montaje (en /etc/fstab ), y si el hardware está realizando un almacenamiento en caché de escritura fuera de orden, se corre el riesgo de una corrupción grave del sistema de archivos durante una falla. [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 fuera de orden (debido a que los discos duros modernos almacenan las escrituras en caché 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 una falla irrecuperable antes de que se escriban los otros bloques, será necesario reiniciar el sistema. Al reiniciar, el sistema de archivos reproducirá el registro de forma normal 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 el disco inacabada anterior continuará, pero utilizando datos de diario corruptos. El sistema de archivos sobrescribirá por error los datos normales con datos corruptos mientras reproduce el diario. Si se hubieran utilizado sumas de comprobación, donde los bloques de la transacción del "ganador falso" se etiquetaran con una suma de comprobación mutua, el sistema de archivos podría haberlo sabido mejor y no haber reproducido los datos corruptos en el disco. Se ha añadido la suma de comprobación del diario a ext4. [35]
Los sistemas de archivos que pasan por la interfaz del asignador de dispositivos (incluidas las implementaciones de RAID y LVM de software) pueden no admitir 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 prácticas, es posible realizar un orden de escritura confiable desactivando la caché de escritura del disco y utilizando la data=journalopción de montaje. [32] Puede ser necesario desactivar la caché de escritura del disco incluso cuando hay 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 la caché de escritura de la unidad en respuesta a esa llamada. [39] También hay un problema potencial con la implementación de la barrera relacionado con el manejo de errores durante eventos, como una falla de la unidad. [40] También se sabe que a veces algunas tecnologías de virtualización no reenvían correctamente los comandos fsync o flush 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 aún así anuncian que es compatible y no devuelven ningún error cuando se usa. [42] Hay tantas formas de manejar fsync y el manejo de caché de escritura de manera incorrecta, 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 crea que sean los componentes individuales.
Ext3 almacena las fechas como tiempo Unix utilizando cuatro bytes en el encabezado del archivo. 32 bits no dan suficiente alcance 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 a 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 gran avance, 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, confiabilidad y facilidad de administración". [45] Btrfs también tiene "varias de las mismas ideas de diseño que tenía reiser3 / 4 ". [46]
{{cite journal}}: Requiere citar revista |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 quedaban disponibles más de 900 GB del espacio total en disco de 1,4 TB.