Guía avanzada de implementación de Sistemas de Ficheros: Introducción a ext3

1.  Introducción

En los pasados apartados, hemos tomado una especie de camino alternativo observando sistemas de ficheros no tradicionales como tmpfs y devfs. Ahora es el momento de retornar a los sistemas de ficheros basados en disco, y lo haremos echando un vistazo a ext3. El sistema de ficheros ext3, diseñado por el Dr. Stephen Tweedie, está construido en el marco del ya existente ext2; de hecho, ext3 es muy similar a ext2 excepto por una pequeña (pero importante) diferencia -- soporta diario de transacciones (journaling). A pesar de esta nueva capacidad añadida, creo que se pueden encontrar otras capacidades sorprendentes e intrigantes. En este artículo proporcionaré un buen entendimiento acerca de cómo ext3 se compara con otros sistemas de ficheros con capacidad para un diario de transacciones disponibles actualmente. En mi siguiente artículo obtendremos un ext3 funcionando correctamente.

2.  Entender ext3

De este modo, ¿cómo se compara ext3 con ReiserFS? En los artículos previos he explicado porqué ReiserFS es adecuado para manejar pequeños archivos (menores a 4K) y, en ciertas situaciones, el rendimiento de ReiserFS con los archivos pequeños es de diez a quince veces superior a ext2 o ext3. De cualquier forma, aunque ReiserFS tiene grandes ventajas, también presenta grandes inconvenientes. En la implementación actual de ReiserFS (versión 3.6), ciertos patrones de accesos a ficheros pueden dar como resultado un peor rendimiento que con ext2 o ext3, en concreto, cuando se leen grandes directorios de correo. Además ReiserFS no posee un buen expediente de compatibilidad con NFS y tiene un rendimiento pobre con archivos fragmentados. En contraste, ext3 es un sistema de ficheros muy adecuado para cualquier propósito. Es muy parecido a ext2; no va a proporcionar la extraordinaria rapidez que ReiserFS proporciona con ficheros pequeños, pero tampoco va a proporcionar un rendimiento o funcionamiento inadecuados.

Una de las cosas buenas de ext3 es que, dado que está basado en el código de ext2, tanto el formato de ext3 como el de ext2 son idénticos en el disco; esto significa que un sistema de ficheros ext3 desmontado limpiamente puede ser montado como ext2 sin el más mínimo problema. Y esto no es todo. Debido al hecho de que tanto ext2 como ext3 utilizan los mismos metadatos, es posible actualizar de ext2 a ext3 sin problemas. Sí, tal como se lee. Actualizando algunas herramientas clave del sistema, instalando un núcleo 2.4 moderno y tecleando un único comando tune2fs por sistema de archivos, se pueden convertir los servidores con sistemas de archivos ext2 en sistemas con diario de transacciones ext3. Incluso se puede hacer esto mientras los sistemas ext2 están montados. La transición es segura, reversible e increíblemente fácil, y a diferencia de una conversión a XFS, JFS, o ReiserFS, no se necesita hacer una copia de seguridad de todos los sistemas de ficheros y restaurarla desde cero. Ahora consideremos por un momento los miles de servidores en producción con ext2 existentes que están a algunos minutos de actualizar a ext3; entonces se tendrá una ligera de idea de la tremenda importancia de ext3 para la comunidad Linux.

Si tuviera que describir ext3 con una sola palabra, lo llamaría "confortable". Es extraordinariamente sencillo habilitar ext3 en un sistema con ext2, después no se encuentra el más mínimo problema de rendimiento. Y hay un aspecto más en el que ext3 figura en el departamento de confort: sucede que ext3 es uno de los sistemas de ficheros con diario de transacciones más seguros disponibles para Linux, como explico a continuación.

3.  Seguridad ext3

Además de ser compatible con ext2, ext3 incluye otros beneficios compartiendo el formato de metadatos de ext2. En primer lugar, los usuarios de ext3 ganan el acceso a una comprobación del sistema de ficheros (fsck) estable como una roca. Se recordará que uno de los factores para usar un sistema de ficheros con diario de transacciones es evitar la necesidad de una comprobación exhaustiva del sistema de ficheros en primer lugar; de cualquier forma, si se terminan obteniendo metadatos corruptos, debido a un núcleo defectuoso, mala unidad de disco duro o rígido, o cualquier otra cosa, se apreciará enormemente el hecho de que ext3 tenga embebida la comprobación del sistema de ficheros ext2 (fsck). En contraste, la comprobación del sistema de ficheros ReiserFS está en su infancia, y corregir metadatos erróneos cuando se encuentran puede llegar a ser un proceso difícil y peligroso.

Diario de transacciones de metadatos únicamente

De forma muy interesante, ext3 maneja las transacciones de forma muy diferente a ReiserFS, XFS, y JFS. Con ReiserFS, XFS, y JFS, el controlador del sistema de ficheros anota las transacciones de los metadatos, pero no toma nota de las transacciones de datos. Con un diario de transacciones de metadatos únicamente, los metadatos del sistema de ficheros serán sólidos como una roca, y probablemente nunca se necesitará hacer una comprobación del sistema de ficheros exhaustiva. De cualquier modo, reinicios inesperados y cuelgues del sistema pueden causar una corrupción significativa de todos los datos modificados recientemente. Ext3 usa un par de de soluciones innovadoras para evitar estos problemas, que observaremos con detalle.

Pero primero, es importante entender cómo tomar nota únicamente de las transacciones de metadatos puede afectarnos. Por ejemplo, digamos que estábamos modificando un archivo llamado /tmp/miarchivo.txt cuando la máquina se colgó inesperadamente, obligando a un reinicio. Si estábamos usando un sistema de ficheros con un diario de transacciones únicamente de metadatos, tal como ReiserFS, XFS, o JFS, los metadatos del sistema de ficheros serían reparados fácilmente, gracias al diario de metadatos, y no necesitaríamos quedarnos esperando a una tediosa comprobación del sistema de ficheros.

De todos modos, existe la posibilidad de que cuando carguemos /tmp/miarchivo.txt con un editor de textos, nuestro archivo no esté perdiendo los cambios recientes únicamente, sino que contenga gran cantidad de datos erróneos o pueda llegar a ser completamente ilegible. Esto no es algo que ocurra siempre, pero puede ocurrir y ocurre a menudo.

He aquí el porqué. Los sistemas con diario de transacciones típicos como ReiserFS, XFS, y JFS prestan una atención especial a los metadatos, pero no prestan demasiada atención a los datos. En el ejemplo anterior, el controlador del sistema de ficheros se encontraba en proceso de modificar varios bloques en el sistema de ficheros. El controlador del sistema de ficheros actualizó los metadatos apropiadamente, pero no tuvo tiempo de volcar los datos desde sus cachés a los nuevos bloques en el disco. Así pues, cuando cargamos /tmp/miarchivo.txt con nuestro editor de textos, todo o parte del archivo será o contendrá "basura" -- bloques de datos que no fueron inicializados a tiempo antes de que el sistema se colgase.

4.  El remedio ext3

Ahora que entendemos este problema de forma general, observemos cómo ext3 implementa las transacciones. Con ext3, el código de las transacciones utiliza un API especial denominado la capa del dispositivo de bloques (Journaling Block Device layer), o JBD. JBD ha sido diseñado con el propósito expreso de implementar un diario de transacciones en cualquier dispositivo de bloque. Ext3 implementa sus transacciones "atrapándolas" con el API JBD. Por ejemplo, el código del sistema de ficheros ext3 informará a JBD de las modificaciones que está realizando, y también solicitará permiso al JBD antes de modificar ciertos datos en el disco. Haciendo ésto, se le proporcionan las oportunidades adecuadas para manejar el diario de transacciones a cargo del controlador del sistema de ficheros ext3 a JBD. Es una buena solución y, dado que JBD está siendo desarrollado como una entidad separada, genérica, puede ser añadido para sumar la capacidad del diario de transacciones a otros sistemas de ficheros en el futuro.

He aquí un par de cosas muy interesantes acerca del diario de transacciones de ext3 manejado por JBD. En primer lugar, el diario de transacciones de ext3 se almacena en un inodo -- básicamente, en un archivo. Dependiendo de cómo se "habilite el sistema de ficheros ext3", podrá o no podrá verse dicho archivo, que se encuentra en /.journal. Por supuesto, almacenando el diario de transacciones en un inodo, ext3 es capaz de añadir el diario de transacciones al sistema de ficheros sin requerir extensiones innecesarias a los metadatos de ext2. Ésta es una de las claves por las que el sistema de ficheros ext3 mantiene su compatibilidad con los metadatos de ext2, y además, con el controlador del sistema de ficheros ext2.

5.  Diferentes remedios para el diario de transacciones

De forma no muy sorprendente, se muestra que hay varias formas de implementar un diario de transacciones. Por ejemplo, el desarrollador de un sistema de ficheros puede desarrollar uno que almacene montones de bytes que deben ser modificados en el sistema de ficheros anfitrión. La ventaja de este remedio es el diario de transacciones será capaz de almacenar muchas pequeñas modificaciones al sistema de ficheros de forma muy eficiente, dado que únicamente necesitará almacenar los bytes individuales que deben ser modificados y nada más.

JBD toma otro, y en ciertos aspectos mejor, remedio. En lugar de almacenar gran cantidad de bytes que necesitan ser modificados, JBD almacena los bloques completos de datos modificados en sí mismos. El controlador del sistema de ficheros también utiliza este remedio y almacena réplicas completas de los bloques modificados (tanto de 1K, 2K ó 4K) en la memoria para controlar las operaciones IO (entrada/salida) pendientes. En principio, ésto puede parecer una pérdida de recursos completamente innecesaria. Después de todo, los bloques completos contienen datos modificados pero además pueden contener datos sin modificar (ya presentes en el disco) también.

El remedio que JBD usa se denomina diario de transacciones físico, lo que significa que JBD utiliza bloques físicos completos para implementar su diario de transacciones. Por contra, el remedio consistente en almacenar montones de bytes modificados en lugar de bloques completos se denomina diario de transacciones lógico, y es el remedio que utiliza XFS. Dado que ext3 utiliza el diario de transacciones físico, un diario de transacciones ext3 dejará, relativamente, una mayor huella en el disco que, digamos, el diario de transacciones de un sistema de ficheros XFS. Pero dado que ext3 usa bloques completos internamente y en su diario de transacciones, ext3 no se enfrenta a toda la complejidad a la que se enfrentaría con la implementación de un diario de transacciones lógico. Además, el uso de bloques completos permite a ext3 realizar algunas optimizaciones adicionales, tales como "tomar huella" de múltiples operaciones pendientes IO (entrada/salida) dentro de un solo bloque en la misma estructura de la memoria. Ésto, además, permite a ext3 escribir todos esos cambios en el disco en una sola operación de escritura, en lugar de en muchas. Añadiendo a ésto que dado que los datos literales de los bloques son almacenados en la memoria, apenas se requiere ninguna modificación en la memoria antes de escribirlos al disco, reduciendo mucho la sobrecarga en la CPU.

6.  Ext3, protector de datos

Y ahora, finalmente, veremos cómo ext3 proporciona un diario de transacciones de datos y metadatos efectivo, evitando el problema de la corrupción de datos que he descrito anteriormente en este artículo. De hecho, ext3 tiene actualmente dos formas de asegurar la integridad de datos y metadatos.

Originalmente, ext3 fue diseñado para realizar un diario de transacciones de datos y metadatos completo. En este modo (denominado modo "data=journal"), el JBD anota todas las modificaciones al sistema de ficheros, tanto si son hechas a datos como a metadatos. Dado que se anotan tanto las modificaciones de datos como de metadatos, JBD puede puede usar el diario para devolver tanto los datos como los metadatos a un estado consistente. El inconveniente de realizar un diario completo de transacciones de datos es que puede ser lento, aunque se puede reducir esta lentitud en su rendimiento configurando un diario de transacciones relativamente grande.

Se ha introducido recientemente un nuevo modo de diario de transacciones a ext3 que proporciona los beneficios de un diario completo de transacciones pero sin introducir este severo inconveniente en su rendimiento. Este nuevo modo únicamente incluye los metadatos en su diario. De cualquier forma, el controlador del sistema de ficheros ext3 sigue la pista a los bloques particulares de datos que corresponden a cada actualización de los metadatos, agrupándolos en una sola entidad denominada transacción. Cuando una transacción se aplica al sistema de ficheros adecuadamente, se escriben primero en el disco los bloques de datos. Una vez se han escrito, las modificaciones de los metadatos se escriben en el diario. Utilizando esta técnica (denominada modo "data=ordered"), ext3 puede proporcionar consistencia tanto en datos como en metadatos, a pesar de que únicamente se almacenan en el diario las modificaciones de metadatos. ext3 usa este modo por defecto.

7.  Conclusión

Durante estos días, se encuentra mucha gente tratando de determinar cuál es el mejor sistema de ficheros con diario de transacciones para Linux. En realidad, no hay ningún sistema de ficheros perfecto para cada aplicación concreta; cada uno tiene sus puntos fuertes. Este es uno de los puntos fuertes de disponer de tantos sistemas de ficheros de nueva generación entre los que elegir. Así que, en lugar de elegir arbitrariamente el "mejor" sistema de ficheros y utilizarlo para cualquiera de sus aplicaciones concebibles, es preferible entender los puntos fuertes y débiles de cada sistema de ficheros de forma que se pueda hacer una elección racional de cuál se debe usar.

Ext3 tiene un buen número de puntos fuertes. Ha sido diseñado para ser muy fácil de utilizar. Está basado en el sólido código de ext2 e incluye la excelente herramienta fsck. Las capacidades del diario de transacciones de ext3 se han diseñado especialmente para asegurar la integridad tanto de datos como de metadatos. Las cosas como son, ext3 es un sistema de ficheros excelente, y un gran sucesor del ahora venerable sistema de ficheros ext2. En mi siguiente artículo obtendremos un sistema de ficheros ext3 operativo. Hasta entonces pueden utilizarse los siguientes recursos.

8.  Recursos

Puede leerse una transcripción completa (en inglés) de la presentación del Dr. Stephen Tweedie del sistema de ficheros con diario de transacciones Ext3, realizada en el simposio de Linux en Ottawa, en julio del 2000.

Se puede encontrar más información acerca de cómo usar ext3 con los núcleos 2.4 en la página de Andrew Morton ext3 para 2.4. Andrew Morton fue la persona encargada de portar ext3 al núcleo 2.4, y proporcionó una asistencia extraordinaria para escribir este artículo. Si no se desea aguardar a mi siguiente artículo, Andrew tiene una buena página de uso de ext3 y el 2.4 (en inglés) que muestra cómo obtener un sistema ext3 operativo en muy poco tiempo.

Para estar al día de los últimos desarrollos de ext3, hay que asegurarse de visitar la lista de correo de los usuarios ext3. Por supuesto, se puede suscribir a la misma también.

Puede tomarse el tutorial libre de Daniel Robbins acerca de los fundamentos de JFS (en inglés) en developerWorks.

Se pueden buscar más recursos Linux en developerWorks.

Se pueden buscar aún más recursos de código abierto en developerWorks.

9.  Acerca del autor

Daniel Robbins vive en Albuquerque, New Mexico. Fue el Presidente/CEO de Gentoo Technologies Inc., el Arquitecto Jefe del Proyecto Gentoo y contribuye como autor de varios libros publicados por MacMillan: Caldera OpenLinux Unleashed, SuSE Linux Unleashed, y Samba Unleashed. Daniel se ha visto involucrado en el mundo de las computadoras de algún modo desde segundo grado cuando se expuso al lenguaje de programación Logo y a una potencialmente letal dosis de Pac Man. Ésto probablemente explica porqué ha sido un artista de gráficos en SONY Electronic Publishing/Psygnosis. Daniel disfruta pasando el tiempo con su mujer Mary y con su hija, Hadassah. Se puede contactar con Daniel en drobbins@gentoo.org.