¡Que todos tengan un excelente fin de semana! Te invitamos a una clase demo gratuita , que será impartida por Andrei Buranov — especialista en sistemas UNIX de Mail.Ru Group. También publicamos un artículo de Jonathan Corbet — Editor Ejecutivo en LWN.net.
Los sistemas de archivos con journaling prometen liberar a los administradores de sistemas de problemas con la corrupción de discos en caso de fallos del sistema. Incluso sin ejecutar una verificación de la integridad del sistema de archivos. Aunque, en realidad, todo es un poco más complicado. Y como demuestra un reciente debate, puede ser incluso más confuso de lo que muchos de nosotros pensamos, ya que garantizar la integridad de los sistemas de archivos con journaling afecta el rendimiento.
Un sistema de archivos, como ext3, utiliza un área separada en el disco llamada journal. Al realizar cambios en los metadatos del sistema de archivos, estos cambios se registran primero en el journal sin modificar el resto del sistema de archivos. Después de registrar todos los cambios en el journal, se añade un «bloque de confirmación» que indica la finalización de la transacción. Y solo después de registrar el bloque de confirmación, la transacción se hace efectiva y los metadatos modificados se escriben en el disco. Si el sistema falla en algún momento, la información en el journal permite concluir de manera segura y evitar la corrupción del sistema de archivos debido a que solo se actualizaron parcialmente los metadatos.
Sin embargo, hay un inconveniente: el código del sistema de archivos debe estar absolutamente seguro de que toda la información de la transacción ya se ha escrito en el journal antes de que se registre el bloque de confirmación. Simplemente registrar las operaciones en el orden correcto no es suficiente: los discos modernos soportan grandes cachés internas y reordenan las operaciones para mejorar el rendimiento. Por lo tanto, antes de registrar el bloque de confirmación, es necesario indicar de manera explícita que todos los datos del journal se transfieran al disco. Si el bloque de confirmación se registra antes, el journal puede corromperse. Para resolver este problema se utilizan barreras. Esencialmente, una barrera prohíbe la escritura de cualquier bloque después de la barrera hasta que todos los bloques escritos antes de la barrera se hayan transferido al disco. Al utilizar barreras, los sistemas de archivos garantizan la coherencia de las estructuras de archivos.
Pero hay un problema más: los sistemas de archivos ext3 y ext4 no utilizan barreras por defecto. Hay una opción disponible, pero si el administrador no las activa explícitamente, esos sistemas de archivos funcionan sin barreras, aunque en algunas distribuciones (por ejemplo, SUSE) los valores predeterminados son diferentes. Eric Sandeen recientemente decidió que era necesario cambiar esta situación y , que modifica la configuración predeterminada para ext3 y ext4. Y entonces comenzó un intenso debate.
Andrew Morton respondió , por qué el valor predeterminado es exactamente ese:
La última vez que intentamos cambiar esto, el rendimiento en muchas cargas de trabajo disminuyó en un 30%, así que horrorizado deseché todos esos parches. Creo que no podemos permitir eso y ralentizar las máquinas de todos de manera tan grave...
No hay soluciones perfectas aquí, y me inclino a no despertar al perro dormido y dejar los valores predeterminados a criterio de los desarrolladores de distribuciones.
Por lo tanto, las barreras están desactivadas por defecto, ya que afectan seriamente el rendimiento. Además, los sistemas de archivos se utilizan con éxito sin barreras. Los informes de corrupción del sistema de archivos ext3 son escasos y raros.
Pero no es solo suerte. Ted Ts'o esto se debe a que el diario de ext3/ext4 generalmente se coloca de manera continua. Primero, el controlador del sistema de archivos intenta crearlo de forma continua. Segundo, el diario generalmente se crea simultáneamente con el sistema de archivos, cuando es fácil encontrar un espacio continuo. La continuidad y el orden son útiles no solo para el rendimiento, sino también para prevenir el reordenamiento. Normalmente, el bloque de compromiso se colocará inmediatamente después de los demás datos en el diario, por lo que el disco no tiene motivos para reordenar. El bloque de compromiso se escribe naturalmente en el disco inmediatamente después de las otras entradas del diario.
Sin embargo, nadie afirma que esto siempre será así. Los discos duros pueden comportarse de manera diferente. Además, el diario es un búfer circular. Por lo tanto, cuando una transacción se escribe al final del diario, el bloque de compromiso puede estar en un bloque anterior, delante de otras entradas del diario. Así que siempre existe la posibilidad de corrupción. De hecho, Chris Mason tiene algo para esto. No hay duda de que trabajar sin barreras es menos seguro que hacerlo con ellas.
Si estás dispuesto a aceptar una disminución en el rendimiento, puedes habilitar las barreras. Esto, por supuesto, solo si tu sistema de archivos no se basa en LVM (como ocurre en algunas distribuciones por defecto). Resulta que el mapeador de dispositivos no admite barreras. En otros casos, sería bueno reducir la caída del rendimiento. Y, al parecer, esto se puede lograr.
La implementación actual de ext3 (cuando las barreras están habilitadas) realiza la siguiente secuencia de operaciones para cada transacción:
Los datos se escriben en el registro
Se ejecuta la barrera
Se escribe el bloque de confirmación
Se ejecuta la siguiente barrera
Más tarde, los metadatos se escriben en el disco
En ext4, se puede omitir la primera barrera (paso 2), ya que el sistema de archivos ext4 admite sumas de verificación en el registro.
Si los datos del registro y el bloque de confirmación se reordenan, y la operación se interrumpe debido a una falla, la suma de verificación del registro no coincidirá con la que se almacena en el bloque de confirmación, y la transacción será rechazada.
Chris Mason , que sería "en general seguro" eliminar esta barrera también en ext3, con la posible excepción de cuando el registro llega al final y comienza a escribirse desde el principio.
Otra idea para acelerar el rendimiento es retrasar las operaciones con barreras cuando sea posible. Si no hay una necesidad urgente de escribir los datos en el disco de inmediato, se pueden crear varias transacciones en el registro y escribir en el disco con una sola barrera.
También hay cierto potencial para mejorar mediante un ordenamiento cuidadoso de las operaciones, de modo que las barreras (que generalmente se implementan como solicitudes de "escribir todas las operaciones pendientes en el disco") no fuerzan la escritura de bloques que no requieren un orden específico.
Parece que ha llegado el momento de considerar cómo hacer que el costo de las barreras sea aceptable. Ted Ts’o parece :
Creo que deberíamos habilitar las barreras en ext3/4, y luego trabajar en reducir los costos en ext4/jbd2. Es probable que la gran mayoría de los sistemas no funcionen en condiciones similares a las que utilizó Chris para demostrar el problema, y la seguridad del sistema de archivos por defecto debe ser prioritaria.
El sentido común me dice que este perro ya no está durmiendo y probablemente ladre durante un tiempo. Esto puede preocupar a algunos vecinos, pero es mejor que permitir que muerda.
¿Te interesa desarrollarte en esta dirección? Inscríbete en una clase demo gratuita y participa en la transmisión , que será conducido por Pavel Vikiryuk — operador de comunicación MVNO, ingeniero DevOps.
Fuente: habr.com
