Ext3

ext3, o tercer sistema de archivos extendido, es un sistema de archivos registrado que suele utilizar 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 núcleo principal de Linux en noviembre de 2001 desde 2.4.15 en adelante. 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.

Ventajas

El rendimiento (velocidad) de ext3 es menos atractivo que el de los sistemas de archivos de 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 una copia de seguridad. y restaurar datos. Los puntos de referencia sugieren que ext3 también usa menos potencia de CPU que ReiserFS y XFS. También se considera más seguro que los otros sistemas de archivos de Linux, debido a su relativa simplicidad y su base de pruebas más amplia.

ext3 agrega las siguientes funciones a ext2:

• Un diario
• Crecimiento del sistema de archivos en línea
• Índice HTree para directorios más grandes

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 del sistema de archivos bien probadas y maduras para mantener y reparar los sistemas de archivos ext2 también se usen 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 "moderno" características 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 para la recuperabilidad, es una ventaja significativa. Los metadatos del sistema de archivos están todos en ubicaciones fijas y conocidas, y las estructuras de datos tienen cierta redundancia. En caso de daños significativos en los datos, ext2 o ext3 pueden recuperarse, mientras que un sistema de archivos basado en árbol puede no serlo.

Límites de tamaño

El número máximo de bloques para ext3 es 2³². 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:

Niveles de registro

Hay tres niveles de registro en diario disponibles en la implementación de Linux de ext3:

Diario (riesgo más bajo)

Tanto los metadatos como los contenidos de archivo se escriben en la revista antes de ser comprometidos con el sistema de archivos principal. Debido a que la revista es relativamente continua en el disco, esto puede mejorar el rendimiento, si la revista tiene suficiente espacio. En otros casos, el rendimiento empeora, porque los datos deben ser escritos dos veces, una vez a la revista, y una vez a la parte principal del sistema de archivos.

Pedido (riesgo medio)

Sólo se publican metadatos; los contenidos de archivo no lo son, pero se garantiza que los contenidos de archivo se escriben en disco antes de que los metadatos asociados estén marcados como comprometidos en la revista. Este es el defecto en muchas distribuciones Linux. Si hay una salida de energía o pánico del núcleo mientras se está escribiendo o anexando un archivo, la revista indicará que el nuevo archivo o los datos adjuntos no han sido "commitados", por lo que será purgado por el proceso de limpieza. (Estos apéndices y nuevos archivos tienen el mismo nivel de protección de la integridad que el nivel "revisado".) Sin embargo, los archivos están siendo overwritten puede ser dañado porque la versión original del archivo no se almacena. Por lo tanto es posible terminar con un archivo en un estado intermedio entre nuevo y viejo, sin suficiente información para restaurar uno o el otro (los nuevos datos nunca lo hicieron en disco completamente, y los datos antiguos no se almacenan en ninguna parte). Aún peor, el estado intermedio podría interferir datos antiguos y nuevos, porque el orden de la escritura se deja al hardware del disco.

Escríbase (mayor riesgo)

Sólo se publican metadatos; los contenidos de archivo no lo son. El contenido puede ser escrito antes o después de que la revista sea actualizada. Como resultado, los archivos modificados justo antes de que un accidente se puede corromper. Por ejemplo, un archivo que se adjunta puede ser marcado en la revista como ser más grande de lo que realmente es, causando la basura al final. Las versiones más antiguas de los archivos también podrían aparecer inesperadamente después de una recuperación de la revista. La falta de sincronización entre los datos y la revista es más rápida en muchos casos. JFS utiliza este nivel de periodismo, pero asegura que cualquier "garbage" debido a datos no escritos se cierne en reinicio. XFS también utiliza este tipo de revistas.

En los tres modos, se garantiza que la estructura interna del sistema de archivos sea coherente incluso después de un bloqueo. En cualquier caso, solo se verá afectado el contenido de datos de archivos o directorios que se estaban modificando cuando el sistema colapsó; el resto estará intacto después de la recuperación.

Desventajas

Funcionalidad

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. 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 del inodo de la carpeta principal en la referencia "..").

En ext3, como en 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. Intentar verificar un sistema de archivos que ya está montado en modo de lectura/escritura (muy probablemente) detectará inconsistencias en los metadatos del sistema de archivos. Donde los metadatos del sistema de archivos están cambiando, y fsck aplica cambios en un intento de traer el "inconsistente" metadatos en un "coherente" estado, el intento de "arreglar" las inconsistencias corromperán el sistema de archivos.

Desfragmentación

No existe una 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, e2defrag puede 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.

Existen herramientas de desfragmentación del espacio de usuario, como Shake y defrag. 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 usan al mismo tiempo, Shake intentará escribirlos uno al lado del otro. Defrag funciona copiando cada archivo sobre sí mismo. Sin embargo, esta estrategia solo funciona si el sistema de archivos tiene suficiente espacio libre. No existe una verdadera herramienta de desfragmentación para ext3.

Sin embargo, como establece la Guía del administrador del sistema Linux, "los sistemas de archivos modernos de Linux mantienen la fragmentación al mínimo manteniendo todos los bloques en un archivo juntos, incluso si no se pueden almacenar en forma consecutiva. sectores Algunos sistemas de archivos, como ext3, asignan 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."

Si bien ext3 es resistente a la fragmentación de archivos, ext3 puede fragmentarse con el tiempo o por patrones de uso específicos, como escribir lentamente archivos grandes. En consecuencia, ext4 (el sucesor de ext3) tiene una utilidad de desfragmentación del sistema de archivos en línea e4defrag y actualmente admite extensiones (regiones de archivos contiguos).

Recuperar

ext3 no admite la recuperación de archivos eliminados. El controlador ext3 elimina archivos de forma activa borrando los inodos de los archivos por razones de seguridad contra accidentes.

Todavía existen varias técnicas y algunos programas gratuitos y patentados para la recuperación de archivos eliminados o perdidos mediante el análisis diario del sistema de archivos; sin embargo, no garantizan la recuperación de ningún archivo específico.

Compresión

e3compr es un parche no oficial para ext3 que realiza una compresión transparente. Es un puerto directo de e2compr y aún necesita más desarrollo. Se compila y arranca bien con núcleos ascendentes, pero el registro en diario aún no está implementado.

Falta de compatibilidad con instantáneas

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 de nivel de volumen que ocupan menos espacio y son proporcionadas por Linux LVM. El sistema de archivos Next3 es una versión modificada de ext3 que ofrece compatibilidad con instantáneas, pero conserva la compatibilidad con el formato en disco ext3.

Sin suma de verificación en el diario

ext3 no realiza sumas 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 desordenado, se ejecuta el riesgo de corrupción grave del sistema de archivos durante un bloqueo. 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 escrituras en caché para amortizar las velocidades de escritura), es probable que uno 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 estaba etiquetada con un bloque de confirmación válido). La escritura de disco inconclusa anterior continuará, pero utilizando datos corruptos del diario. Por lo tanto, el sistema de archivos sobrescribirá por error los datos normales con datos corruptos mientras reproduce el diario. Si se han utilizado sumas de comprobación, donde los bloques del "ganador falso" transacción se etiquetaron con una suma de verificación mutua, el sistema de archivos podría haberlo sabido mejor y no haber reproducido los datos corruptos en el disco. Se ha agregado la suma de verificación del diario a ext4.

Es posible que los sistemas de archivos que pasan por la interfaz del mapeador de dispositivos (incluidas las implementaciones LVM y RAID de software) no admitan barreras y emitan una advertencia si se usa esa opción de montaje. 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 genera una advertencia similar. En estas situaciones, donde las barreras no son compatibles o prácticas, es posible un orden de escritura confiable desactivando el caché de escritura del disco y usando el data=journal. Es posible que sea necesario desactivar la memoria caché de escritura del disco incluso cuando haya barreras disponibles.

Las aplicaciones como las bases de datos esperan una llamada a fsync() para eliminar las escrituras pendientes en el disco, y la implementación de la barrera no siempre borra la memoria caché de escritura de la unidad en respuesta a esa llamada. También existe un problema potencial con la implementación de la barrera relacionado con el manejo de errores durante los eventos, como una falla en la unidad. También se sabe que, a veces, algunas tecnologías de virtualización no envían correctamente los comandos fsync o flush a los dispositivos subyacentes (archivos, volúmenes, disco) desde un sistema operativo huésped. De manera similar, algunos discos duros o controladores implementan el vaciado de caché de forma incorrecta o no lo implementan, pero aun así anuncian que es compatible y no devuelven ningún error cuando se usa. Hay tantas formas de manejar fsync y escribir el manejo de la memoria caché incorrectamente, que es más seguro asumir que el vaciado de la memoria caché no funciona a menos que se pruebe explícitamente, independientemente de cuán confiables se crea que son los componentes individuales.

Extinción cercana al tiempo debido a la limitación del sello de fecha

Ext3 almacena fechas como tiempo Unix utilizando cuatro bytes en el encabezado del archivo. 32 bits no brinda suficiente alcance para continuar procesando archivos más allá del 18 de enero de 2038: el problema del año 2038.

Ext4

fsck time dependence on inode count (ext3 vs. ext4)

El 28 de junio de 2006, Theodore Ts'o, el desarrollador principal de ext3, 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 gran avance, usa tecnología antigua y es un recurso provisional; Ts'o cree que Btrfs es la mejor dirección, porque "ofrece mejoras en escalabilidad, confiabilidad y facilidad de administración". Btrfs también tiene "varias de las mismas ideas de diseño que tenía reiser3/4".