Guía avanzada de implementación de Sistemas de Ficheros, Parte 8Voy a ser honesto. En este artículo, pretendía mostrar cómo obtener un sistema ext3 operativo y funcional. A pesar de que fue lo que dije que iba a hacer, no lo voy a hacer. La excelente página de Andrew Morton "Cómo usar ext3 con los núcleos 2.4" (ver los Recursos más adelante en este artículo) explica muy bien cómo habilitar ext3 en nuestro sistema, así pues no es necesario que repita aquí esa misma base. En su lugar, voy a profundizar en algunos aspectos más sustanciales de ext3, si se está preparado para obtener un sistema ext3 operativo y funcional, consultar la página de Andrew. 2. Actualización al núcleo 2.4 Primero, comencemos con una actualización al núcleo 2.4. La última vez que traté la estabilidad del núcleo 2.4 fue cuando hablé acerca de ReiserFS. En aquellos momentos, encontrar un núcleo 2.4 estable era una batalla, y recomendé usar en aquel momento el más conocido e innovador para la fecha núcleo 2.4.4-ac9 -- especialmente para todos aquellos que planeaban usar ReiserFS en entornos en producción. Como es lógico, han ocurrido muchas cosas desde el 2.4.4-ac9, y es el momento de buscar núcleos mucho más actuales. Con el núcleo 2.4.10, la serie 2.4 alcanzó un nuevo nivel de rendimiento y escalabilidad (algo que habíamos anticipado desde hacía mucho). ¿Qué fue lo que permitió crecer a Linux 2.4? Usando el acrónimo: VM. Linus, reconociendo que la serie 2.4 no tenía un rendimiento espectacular, extrajo el código problemático de la VM de Linux y lo reemplazó con la implementación de la VM de Andrea Archangeli. La nueva implementación de la VM de Andrea (que apareció por primera vez con el 2.4.10) era extraordinaria; realmente aceleró el núcleo y lo hizo responder con mucha más rapidez. El 2.4.10 fue un punto decisivo en el desarrollo del núcleo Linux 2.4; hasta entonces, las cosas no parecían ir demasiado bien, y muchos de nosotros nos preguntábamos porqué no eramos desarrolladores de FreeBSD. Todos debemos agradecer a Linus su heroismo al hacer un cambio tan importante (aunque muy necesario) en la serie de los núcleos estables 2.4. Dado que el código de la VM de Andrea necesitaba algo de tiempo para ser integrado sin fisuras con el resto del núcleo, se usará el 2.4.13+. Aún mejor, se usará el 2.4.16+, dado que el código del sistema de ficheros ext3, sólido como una roca, se integró definitivamente en la versión 2.4.15-pre2 del núcleo Linux, no hay ninguna razón para evitar usar un núcleo 2.4.16+, y ésto hará mucho más fácil la labor de obtener un sistema ext3 operativo y funcional. Únicamente es necesario recordar que ya no es necesario aplicar el parche ext3 como se explica en la página de Andrew (ver los Recursos). Linus ya lo ha añadido por nosotros. :) Como puede apreciarse, recomiendo usar un 2.4.16+ en lugar de un 2.4.15+, y con razón. Con la versión 2.4.15-pre9, se introdujo un serio error que producía una corrupción masiva del sistema de ficheros. Hasta la versión 2.4.16-pre1 no se pudo identificar y solucionar el problema, resultando en un gran número de núcleos (incluído el 2.4.15) que deben evitarse a toda costa. Eligiendo un núcleo 2.4.16+ nos permite evitar este inconveniente por completo. 3. Ordenadores portátiles... ¿con cuidado? Ext3 tiene la reputación de ser un sistema de ficheros sólido como una roca, así que me sorprendió mucho que algunos usuarios de ordenadores portátiles tuvieran problemas de corrupción en su sistema de ficheros cuando se pasaron a ext3. En general, es tentador reaccionar ante este tipo de informes evitando ext3 por completo; de cualquier forma, informándome un poco más al respecto, descubrí que los problemas de corrupción en el disco no tenían nada que ver con ext3 en sí mismo, estaban ocasionados sólo por ciertas unidades de disco de ordenadores portátiles. Puede no saberse esto, pero la mayoría de las unidades de disco duro modernas tienen algo denominado "caché de escritura", usado por la unidad para almacenar las operaciones de escritura aún pendientes. Almacenando las escrituras pendientes en la caché, el microcódigo de la unidad de disco duro puede reorganizarlas y reagruparlas de forma que sean escritas al disco de la forma más rápida posible. En líneas generales la caché de escritura se considera una muy buena cosa (Léase la explicación y la opinión de Linus acerca de la caché de escritura "write cache" en Recursos). Lamentablemente, ciertas unidades de disco duro en ordenadores portátiles tienen la dudosa cualidad de ignorar cualquier petición oficial ATA de vaciar la caché y escribirla al disco. Esto no es como resultado de un diseño maravilloso, aunque ha sido permitido por la especificación ATA hasta hace poco. Con este tipo de unidades, no hay manera de que el núcleo pueda garantizar que un bloque ha sido escrito en el disco. A pesar de que esto suena como un problema muy espinoso, este asunto en particular puede no ser la causa de los problemas de corrupción de datos que la gente ha estado experimentando. Sin embargo, aún empeora más. Algunos discos duros modernos de ordenadores portátiles tienen el dañino hábito de perder el caché de escritura cada vez que el ordenador se reinicia o se suspende. Obviamente, si un disco duro tiene ambos problemas, va a corromper datos muy a menudo, y no hay nada que Linux pueda hacer al respecto para prevenirlo. Entonces, ¿cuál es la solución? Si se tiene un ordenador portátil, hay que tratarlo con mucho cuidado. Hay que hacer una copia de seguridad de todos nuestros archivos importantes antes de realizar cualquier modificación importante al sistema de ficheros. Si se experimentan problemas de corrupción de datos como los que he descrito anteriormente, sobre todo con ext3, entonces el fallo es de la unidad de disco de nuestro ordenador portátil. En este caso, podemos contactar con el fabricante de nuestro ordenador portátil y solicitar una unidad de disco que reemplace a la que tenemos. Con suerte, en unos pocos meses, estas unidades defectuosas desaparecerán del mercado y nunca más tendremos que preocuparnos por este problema. Ahora que hemos perdido todos nuestros miedos, vamos a echar un vistazo a las distintas opciones del diario de transacciones. 4. Opciones del diario de transacciones y latencia de escritura Ext3 nos permite elegir uno de un total de tres modos de tomar nota de los datos en el diario de transacciones al montar el sistema de ficheros: data=writeback, data=ordered, y data=journal. Para especificar un modo, se puede añadir la cadena de caracteres apropiada (data=journal, por ejemplo) a la sección de opciones en /etc/fstab, o especificar la opción -o data=journal cuando ejecutemos mount directamente. Si queremos especificar el modo en que toma nota de los datos el diario de transacciones de nuestro sistema de ficheros raíz (data=ordered es el valor por defecto), se puede usar una opción especial de inicio del núcleo denominada rootflags. Así, si queremos poner nuestro sistema de ficheros raíz en el modo en que toma nota de absolutamente todos los datos en su diario de transacciones, añadiremos rootflags=data=journal a los parámetros de inicio del núcleo. Con el modo data=writeback, ext3 no toma nota en su diario de transacciones de ningún tipo de datos, proporcionando algo muy similar a lo que encontramos en los sistemas de ficheros XFS, JFS, y ReiserFS (metadatos únicamente). Como expliqué en mi anterior artículo, esto puede causar que los archivos modificados recientemente se corrompan en el caso de un reinicio inesperado. A pesar de este inconveniente, el modo data=writeback es el que debe proporcionar el mejor rendimiento de ext3 bajo cualquier circunstancia. En el modo data=ordered, ext3 sólo anota en el diario los metadatos, pero agrupa los metadatos y los datos en una única unidad denominada transacción. Cuando llega el momento de escribir los nuevos metadatos en el disco, los bloques asociados de datos se escriben primero. El modo data=ordered resuelve el problema de la corrupción de datos que se encuentra con el modo data=writeback y con la mayoría de sistemas de ficheros con diario de transacciones y lo hace sin requerir tomar nota en el diario de transacciones de los datos en absoluto. En general, un sistema de ficheros ext3 con data=ordered tendrá un rendimiento algo menor que los sistemas de ficheros con data=writeback, pero significativamente superior a las opciones que toman nota de todos los datos en su diario de transacciones. Cuando se añaden datos a los archivos, el modo data=ordered proporciona todas las garantías de integridad ofrecidas por el modo ext3 en el que se toma nota de absolutamente todos los datos en el diario de transacciones. De cualquier modo, si el sistema se cuelga justo en el momento en el que una parte de un archivo estaba siendo sobrescrita, es posible que la parte que se estaba escribiendo contenga una combinación de bloques originales esparcidos entre los bloques actualizados. Esto se debe a que data=ordered no proporciona ninguna garantía acerca de qué bloque se sobrescribirá primero, por lo que no se puede asumir que dado que el bloque x se ha actualizado, el bloque x-1 ha sido actualizado y sobrescrito también. En su lugar, data=ordered deja el orden de escritura a cargo de la caché de escritura de la unidad de disco. En general, esta limitación no suele terminar impactando negativamente en la gente, dado que los añadidos a archivos son mucho más comunes que sobrescribir archivos. Por esta razón, el modo data=ordered es una buena opción con mayor rendimiento que anotar todos los datos en el diario de transacciones. Con el modo data=journal se anotan en el diario de transacciones todos los datos y metadatos. Todos los nuevos datos se escriben en el diario primero, y después en su localización final. En caso de algún cuelgue, el diario de transacciones contendrá tanto los datos como los metadatos y podrá ponerse en juego de nuevo, proporcionando tanto los datos como los metadatos en un estado consistente. Teóricamente, el modo data=journal es el más lento de todos, dado que los datos se escriben en el disco dos veces en lugar de una. De todos modos, resulta que en ciertas situaciones, el modo data=journal puede ser extraordinariamente rápido. Andrew Morton, después de leer informes en LKML de que los sistemas de ficheros ext3 con data=journal estaban proporcionando un increíble rendimiento interactivo, decidió realizar un pequeño test. Primero, creó un archivo de comandos diseñado para escribir datos en un sistema de ficheros de prueba tan rápido como fuera posible:
Mientras los datos se escribían en el sistema de ficheros de prueba, intentó leer 16MB de datos de otro sistema de ficheros ext2 en el mismo disco, cronometrando los resultados:
Los resultados fueron asombrosos. El modo data=journal permitió que 16-meg-file se leyera de 9 a más de 13 veces más rápido que en el resto de modos ext3, ReiserFS, e incluso ext2 (sin ralentizarse por un diario de transacciones):
Andrew repitió este test, pero trató de leer un archivo de 16MB desde el mismo sistema de ficheros de prueba (en lugar de otro distinto) y obtuvo idénticos resultados. Por tanto, ¿qué significa ésto? De algún modo, resulta que data=journal satisface adecuadamente aquellas situaciones en las que los datos necesitan ser leídos y escritos al disco al mismo tiempo. Por lo tanto, el modo ext3 data=journal, que se suponía el más lento de todos los modos en aproximadamente cualquier condición, actualmente resulta que tiene una gran ventaja en cuanto a rendimiento en entornos muy ocupados dónde el rendimiento interactivo IO necesita maximizarse. Después de todo, data=journal no es tan inactivo como se pensaba. Andrew continua intentando encontrar porqué el modo data=journal está funcionando mejor que cualquiera de los restantes. Cuando lo haga, quizá sea capaz de añadir las modificaciones necesarias al resto de ext3 para que los modos data=writeback y data=ordered experimenten dichos beneficios también. Algunas personas han tenido problemas concretos de rendimiento mientras usaban el modo data=journal de ext3 en servidores muy ocupados -- servidores NFS muy ocupados, en concreto. Cada treinta segundos, el servidor experimenta una gran tormenta de escrituras en el disco, causando al sistema que casi se detuviese. Si se experimenta este problema es sencillo resolverlo. Sencillamente se teclea el siguiente comando como administrador (root) para ajustar el algoritmo de vaciado del buffer ocupado:
Esta nueva configuración de bdflush ocasionará que se ejecute kupdate cada 0,6 segundos en lugar de cada 5 segundos. Además, le indica al núcleo que vacíe un buffer ocupado cada 3 segundos en lugar de cada 30, el valor por defecto. Vaciando los datos recientemente modificados más a menudo al disco, se pueden evitar estas tormentas de escrituras. Es ligeramente menos eficaz hacer las cosas de esta manera, dado que el núcleo tendrá menos oportunidades de hacer escrituras combinadas. Pero, para un servidor ocupado, las escrituras ocurrirán de forma mucho más consistente, y el rendimiento interactivo se mejorará considerablemente. Hemos cubierto ext3. En mi siguiente artículo exploraremos las maravillas de... ¡XFS!
|
|
